FuncSpec v2.00 (For6.3)

Functional Specification (2005415) - Rev. 2.00 (for 6.
3)
1 Introduction
I/A Series Intelligent SCADA System
Functional Specification
for the: Master Station
Document ID: Revision:

2005415 2.00 (for 6.3)

Page 1 of 215
Functional Specification (2005415) - Rev. 2.00 (for 6.3)
1 Introduction
Table of Contents
1 Introduction ............................................................................................................................... 11 1.1 2 iSCADA Master Station Overview .................................................................................... 12
HMI.............................................................................................................................................. 20 2.1 The HMI Station ................................................................................................................ 20 2.1.1 Solaris Database HMI Station ........................................................................... 20 2.1.2 Solaris Databaseless HMI Station ..................................................................... 20 2.1.3 Windows NT/2000 HMI Station (Databaseless) ................................................ 21 2.1.4 iSCADA WebConnect (iWeb) ............................................................................ 21 2.1.5 Domain Support................................................................................................. 22 HMI Data Access Failure and Failover ............................................................................. 22 2.2.1 Server Failure .................................................................................................... 22 2.2.2 HMI Data Access Failover ................................................................................. 23 System Security ................................................................................................................ 23 2.3.1 Authorized User................................................................................................. 24 2.3.2 User Classes ..................................................................................................... 24 2.3.3 Display Access Security Levels......................................................................... 24 2.3.4 SCADA System Capability ................................................................................ 24 HMI Console ..................................................................................................................... 24 2.4.1 Command Window ............................................................................................ 26 2.4.1.1 Audible Alarm..................................................................................... 27 2.4.2 3-Most Recent Alarms Window ......................................................................... 27 2.4.3 Control Window ................................................................................................. 28 2.4.4 User and System Windows ............................................................................... 28 2.4.4.1 Window Notes .................................................................................... 29 2.4.4.2 Date and Time Format ....................................................................... 29 2.4.5 General System Displays .................................................................................. 29 2.4.6 Administrative Displays (Tool Box).................................................................... 30 2.4.7 International HMI Station (Solaris HMI Station)................................................. 34 User Displays .................................................................................................................... 35 2.5.1 Runtime Annotation ........................................................................................... 35 2.5.2 Display Components ......................................................................................... 36 2.5.2.1 Programmable Foreground Display Components ............................. 39 2.5.2.2 Foreground Display DDO Key Concatenation ................................... 39 2.5.3 Zoom and De-Clutter ......................................................................................... 39 2.5.3.1 Zoom Function ................................................................................... 39 2.5.3.2 Zoom Options..................................................................................... 40 2.5.3.3 Features of the Zoom Window........................................................... 40 System Lists...................................................................................................................... 40 2.6.1 Alarm List........................................................................................................... 40 2.6.1.1 Alarm Entry......................................................................................... 41 2.6.1.2 Function Buttons ................................................................................ 42 2.6.2 Event List ........................................................................................................... 43 2.6.2.1 Event Entry......................................................................................... 44 2.6.2.2 Viewing Online Events - Online Event Files as Separate Files ......... 44 2.6.2.3 Viewing Online Events - Online Event Files as Continuous List........ 44 2.6.2.4 Viewing Archived Events.................................................................... 45 2.6.2.5 Other Function Buttons ...................................................................... 45 2.6.2.6 Event Annotation................................................................................ 45 2.6.3 Off-Normal List .................................................................................................. 45 2.6.3.1 Off-Normal Entry ................................................................................ 46 2.6.3.2 Function Buttons ................................................................................ 46 2.6.4 Administrative Tags List .................................................................................... 46 2.6.4.1 Administrative Tags Entry .................................................................. 47 2.6.4.2 Function Buttons ................................................................................ 47 2.6.5 System List Filtering and Sort Options .............................................................. 47 Point Administrative Functions.......................................................................................... 48 2.7.1 Point Palette ...................................................................................................... 48
Page 3 of 215
2.2
2.3
2.4
2.5
2.6
2.7
1 Introduction
2.8
2.9
2.10
2.11
2.12
2.13
2.7.1.1 Function Buttons ................................................................................ 49 2.7.1.2 Demand Scan a point......................................................................... 49 2.7.1.3 Operator Tags and Tag Notes ........................................................... 50 2.7.1.4 Point Information ................................................................................ 50 2.7.1.5 Display (Solaris HMI Station) ............................................................. 50 2.7.1.6 Accumulator Reset............................................................................. 50 2.7.2 Point Attributes .................................................................................................. 51 2.7.2.1 Function Buttons and Fields............................................................... 51 2.7.2.2 Enable/Disable Scanning ................................................................... 52 2.7.2.3 Put Point On/Off Test ......................................................................... 52 2.7.2.4 Change Normal State (Digital Points) ................................................ 52 2.7.2.5 Apply/Remove Manual Override ........................................................ 52 2.7.2.6 Enter Manual Value (or State)............................................................ 53 2.7.2.7 Apply/Remove Substitute Point ......................................................... 53 2.7.3 Analogue Limits ................................................................................................. 53 2.7.3.1 Function Buttons ................................................................................ 55 Supervisory Control .......................................................................................................... 55 2.8.1 Digital Controls .................................................................................................. 56 2.8.2 Analogue Momentary and Scaled Raise/Lower Controls.................................. 56 2.8.3 Analogue Setpoint Controls............................................................................... 57 History ............................................................................................................................... 58 2.9.1 Historical Trend ................................................................................................. 59 2.9.1.1 Time Change Presentation ................................................................ 60 2.9.2 Operator Assignable Trend ............................................................................... 60 2.9.2.1 Select Point for Trend ........................................................................ 60 2.9.2.2 Operator Assignable Trend Display ................................................... 60 2.9.3 Historical Plot..................................................................................................... 62 2.9.4 Historical Tabular............................................................................................... 63 2.9.4.1 Change Only Presentation ................................................................. 64 2.9.4.2 Time Change Presentation ................................................................ 65 2.9.5 History Data Editing........................................................................................... 65 2.9.6 History Utilities ................................................................................................... 66 2.9.6.1 History Storage Statistics ................................................................... 66 2.9.6.2 History Services ................................................................................. 66 History and Event Archive................................................................................................. 67 2.10.1 Archival .............................................................................................................. 67 2.10.2 Retrieval............................................................................................................. 68 History Replay................................................................................................................... 68 2.11.1 History Replay Console Mode ........................................................................... 68 2.11.2 Time Range Selection ....................................................................................... 69 2.11.2.1 Selected Disturbance ......................................................................... 69 2.11.2.2 User Selected Time Range ................................................................ 69 2.11.3 Running in History Replay Console Mode......................................................... 69 2.11.4 Data Displays in History Replay Console Mode................................................ 70 2.11.5 Normal Console Mode....................................................................................... 71 Server Access ................................................................................................................... 71 2.12.1 HMI Station Console Assignment...................................................................... 71 2.12.2 Solaris Databaseless and Windows NT/2000 Servers Overview...................... 71 2.12.3 Database Server User List ................................................................................ 71 2.12.4 Changing Domain.............................................................................................. 71 2.12.5 Changing Database Server ............................................................................... 71 2.12.6 Changing User Class......................................................................................... 71 System Management ........................................................................................................ 72 2.13.1 Database Management ..................................................................................... 72 2.13.1.1 Database List ..................................................................................... 72 2.13.1.2 Process Monitor ................................................................................. 72 2.13.2 Station/Network Management ........................................................................... 72 2.13.2.1 Solaris Stations Network Overview ................................................... 72 2.13.2.2 Network Statistics............................................................................... 72 2.13.3 Communications Management.......................................................................... 73 2.13.3.1 Communications Overview ................................................................ 73
Page 4 of 215
1 Introduction
2.13.3.2 Channel Status................................................................................... 73 2.13.3.3 Route Status ...................................................................................... 73 2.13.3.4 RTU Status......................................................................................... 73 2.13.3.5 RTU Administrative Functions............................................................ 73 2.13.3.6 Communications Statistics ................................................................. 73 2.13.4 Application Management ................................................................................... 74 2.14 HMI Station Logging ......................................................................................................... 75 2.14.1 Printer Summary................................................................................................ 75 2.14.2 Print Screen and Print Window.......................................................................... 75 2.14.2.1 Solaris HMI Station ............................................................................ 75 2.14.2.2 Windows NT/2000 HMI Station .......................................................... 76 2.14.3 Foreground Log ................................................................................................. 76 2.14.3.1 Solaris HMI Station ............................................................................ 76 2.14.3.2 Windows NT/2000 HMI Station .......................................................... 76 2.14.4 Event Logging (Solaris HMI Station) ................................................................. 76 2.14.4.1 Incident Event Log (Solaris HMI Station) ........................................... 76 2.14.4.2 Periodic Event Log (Solaris HMI Station)........................................... 76 2.14.5 Reports .............................................................................................................. 76 2.14.5.1 Task/Report Scheduler ...................................................................... 77 2.15 HMI Background Jobs....................................................................................................... 77 3 FEP ............................................................................................................................................. 79 3.1 3.2 FEP Functionality Table.................................................................................................... 79 Communications Configurations ....................................................................................... 80 3.2.1 Serial Communications...................................................................................... 80 3.2.2 Direct TCP/IP to RTU ........................................................................................ 80 3.2.3 Line Equipment.................................................................................................. 81 3.2.3.1 Communications Line Servers (CLS)................................................. 81 3.2.3.2 Terminal Servers................................................................................ 82 3.2.4 Communications Lines ...................................................................................... 83 3.2.4.1 Dedicated Lines ................................................................................. 83 3.2.4.2 Dialup Lines ....................................................................................... 83 3.2.5 RTUs.................................................................................................................. 83 3.2.5.1 Addressing ......................................................................................... 83 3.2.5.2 Multiple Conitel RTUs with Same Station Address............................ 84 3.2.5.3 Split RTU ............................................................................................ 84 Communications Management ......................................................................................... 84 3.3.1 Communication Routes ..................................................................................... 84 3.3.2 Failure Detection ............................................................................................... 86 3.3.2.1 Request Timeout and Retry ............................................................... 86 3.3.2.2 Route Error Rate ................................................................................ 86 3.3.2.3 Channel Error Rate ............................................................................ 87 3.3.2.4 Equipment/Connection Failure........................................................... 87 3.3.3 Communications Failover/Failback ................................................................... 87 3.3.4 Route Failover/Failback..................................................................................... 87 3.3.4.1 Automatic Fail/Restore....................................................................... 88 3.3.4.2 Manual Fail/Restore ........................................................................... 89 3.3.4.3 Route Health Monitoring and Failback (Serial Communications) ...... 89 3.3.5 Channel Failover/Failback ................................................................................. 89 3.3.5.1 Channel Health Monitoring and Failback (Direct TCP/IP Connections)90 Data Acquisition ................................................................................................................ 90 3.4.1 Scan Requests .................................................................................................. 90 3.4.1.1 Periodic Scan Rate Requests ............................................................ 90 3.4.1.2 Continuous Scan Requests................................................................ 91 3.4.1.3 Demand Scan Requests .................................................................... 91 3.4.1.4 RTU Initiated Scan Requests (IEC 60870-5-101, Conitel) ................ 91 3.4.2 Unsolicited Messages........................................................................................ 91 3.4.3 Priority................................................................................................................ 91 3.4.4 Scan Modes....................................................................................................... 92 3.4.4.1 Normal scanning ................................................................................ 92 3.4.4.2 Master Station and RTU Synchronisation.......................................... 92
Page 5 of 215
3.3
3.4
1 Introduction
3.5
3.6 3.7 4
3.4.4.3 Active Scan Mode .............................................................................. 92 3.4.4.4 Scan Fail Mode .................................................................................. 93 3.4.4.5 Recovery Mode .................................................................................. 93 3.4.4.6 Catchup Mode (optional).................................................................... 93 Communication Protocols ................................................................................................. 94 3.5.1 DNP3 ................................................................................................................. 94 3.5.1.1 Types of Scan Request...................................................................... 94 3.5.1.2 Typical Scan Configuration ................................................................ 94 3.5.2 IEC 60870-5 T101 ............................................................................................. 95 3.5.2.1 Types of Scan Request...................................................................... 95 3.5.2.2 Typical Scan Configuration ................................................................ 96 3.5.3 Conitel C2025 and C300 Protocol..................................................................... 96 3.5.3.1 Types of Scan Request...................................................................... 96 3.5.4 Modbus .............................................................................................................. 97 3.5.4.1 Types of Scan Request...................................................................... 97 Communications Statistics and Status ............................................................................. 97 RTU File Transfer API (DNP3).......................................................................................... 97
Core SCADA .............................................................................................................................. 99 4.1 4.2 Core SCADA Functionality Table...................................................................................... 99 Data Processing.............................................................................................................. 100 4.2.1 Analogue Points .............................................................................................. 100 4.2.1.1 Telemetered Analogue Points - Raw ADC Value Input ................... 100 4.2.1.2 Telemetered Analogue Points - Engineering Value Input................ 102 4.2.1.3 Telemetered Analogue Points - Low Cut/Zero Snap Functions....... 102 4.2.1.4 Telemetered Analogue - Manual Override....................................... 103 4.2.1.5 Telemetered Analogue - Point Substitution ..................................... 103 4.2.1.6 Calculated Analogue Points ............................................................. 104 4.2.1.7 Manual Analogue Points .................................................................. 104 4.2.1.8 Analogue Input Filtering ................................................................... 104 4.2.2 Digital Points.................................................................................................... 104 4.2.2.1 Telemetered Digital Points - One Bit Status Inputs ......................... 104 4.2.2.2 Telemetered Digital Points - Two Bit Status Inputs ......................... 105 4.2.2.3 Telemetered Digital Points - Multi Bit Status Inputs (Conitel Only).. 105 4.2.2.4 Telemetered Digital Points - BCD Conversion (Conitel Only).......... 106 4.2.2.5 Telemetered Digital Points - Single Contact MCD (Conitel Only).... 106 4.2.2.6 Telemetered Digital Points - Double Contact MCD (Conitel Only) .. 106 4.2.2.7 Telemetered Digital - Manual Override ............................................ 106 4.2.2.8 Telemetered Digital - Point Substitution........................................... 107 4.2.2.9 Calculated Digital Points .................................................................. 107 4.2.2.10 Manual Digital Points ....................................................................... 107 4.2.3 Accumulator Points.......................................................................................... 107 4.2.3.1 Master Station Accumulator Point Types......................................... 107 4.2.3.2 RTU Counter Support ...................................................................... 107 4.2.3.3 Telemetered Accumulator Point (TAP) ............................................ 109 4.2.3.4 Calculated Accumulator Point (CAP) Current Value Type............ 110 4.2.3.5 Calculated Accumulator Point (CAP) Completed Value Type ...... 111 4.2.3.6 Quality Propagation.......................................................................... 111 4.2.3.7 Recovery From Out Of Scan............................................................ 111 4.2.3.8 Discontinuity in RTU Accumulator Data........................................... 112 4.2.3.9 Master Station Failure/Restart ......................................................... 113 4.2.3.10 Manual Override............................................................................... 113 4.2.3.11 Database Install ............................................................................... 114 4.2.4 Time Tags........................................................................................................ 114 4.2.4.1 Retrospective History Processing After a Communications Outage (Optional) ......................................................................................................... 115 4.2.5 Conitel SOE Processing .................................................................................. 115 Database Objects (Points) .............................................................................................. 116 4.3.1 Point Quality .................................................................................................... 116 4.3.2 Bad Data Definition.......................................................................................... 119 4.3.3 Quality Flag Propagation (Runtime) ................................................................ 120
Page 6 of 215
4.3
1 Introduction
4.4 5
Core SCADA Initialization ............................................................................................... 122
Alarm Management ................................................................................................................. 123 5.1 Analogue Alarms............................................................................................................. 123 5.1.1 Zone Alarms .................................................................................................... 123 5.1.1.1 Zone Width ....................................................................................... 124 5.1.1.2 Number of Zones ............................................................................. 124 5.1.1.3 Deadbands....................................................................................... 125 5.1.1.4 Critical High/Low Limits.................................................................... 125 5.1.1.5 Display of Alarm Condition............................................................... 126 5.1.2 Flat Line Alarms............................................................................................... 126 Digital Alarms .................................................................................................................. 127 5.2.1 Annunciation of Transient Digital States with DNP Protocol ........................... 128 Point Quality Alarms (Analogue and Digital)................................................................... 128 5.3.1 Cause Alarm .................................................................................................... 128 5.3.2 Suspend Alarm (and Data Unavailable) .......................................................... 128 5.3.3 Cause-Alarm and Suspend-Alarm Point Quality Flags ................................... 129 Alarm Annunciation......................................................................................................... 130 5.4.1 Authorized Controls ......................................................................................... 130 5.4.2 Annunciation Time Delay (Fleeting Change Filtering)..................................... 131 5.4.2.1 Analogue Points ............................................................................... 131 5.4.2.2 Digital Points .................................................................................... 131 Alarm Acknowledgement (Visual) ................................................................................... 132 5.5.1 Alarm Acknowledge - Any Window - Single Point ........................................... 132 5.5.2 Alarm Acknowledge - Any Window - Whole Window (Solaris HMI Station).... 132 5.5.3 Alarm Acknowledge - Alarm List - Single Alarm.............................................. 132 5.5.4 Alarm Acknowledge - Alarm List - Selected Alarms ........................................ 132 5.5.5 Alarm Acknowledge - Alarm List - Whole Page............................................... 132 5.5.6 Alarm Acknowledge - 3-Most Recent Alarms Window - Single Alarm ............ 133 5.5.7 Automatic Alarm Acknowledge........................................................................ 133 Return Digital Point to Normal on Acknowledge............................................................. 133 Alarm Deletion................................................................................................................. 133 5.7.1 Alarm Delete - Alarm List - Selected Alarms ................................................... 133 5.7.2 Alarm Delete - Alarm List - Whole Page.......................................................... 133 5.7.3 Automatic Alarm Deletion ................................................................................ 134 Alarm Inhibit .................................................................................................................... 134 5.8.1 Alarm Inhibit/Enable - All Alarms ..................................................................... 134 5.8.2 Alarm Inhibit/Enable - High Alarms ................................................................. 135 5.8.3 Alarm Inhibit/Enable - Low Alarms .................................................................. 135 5.8.4 Better Alarm Disable and Inhibit ...................................................................... 136 5.8.4.1 Better Alarm Disable (a Configuration Action) ................................. 136 5.8.4.2 Better Alarm Inhibit (an Operator Action)......................................... 136 5.8.5 Alarm Inhibit (All Alarms) - by Point Quality .................................................... 137 Alarm Initialization........................................................................................................... 137
5.2 5.3
5.4
5.5
5.6 5.7
5.8
5.9 6
Event Management.................................................................................................................. 139 6.1 Analogue Events............................................................................................................. 139 6.1.1 Events for Zone Alarms ................................................................................... 139 6.1.2 Events for Flat Line Alarms ............................................................................. 139 Digital Events .................................................................................................................. 139 Events for Point Quality Alarms ...................................................................................... 139 Events for Authorized Controls ....................................................................................... 139 Events for Annunciation Time Delay............................................................................... 139 Event Inhibit .................................................................................................................... 140 6.6.1 Event Inhibit/Enable - All Events ..................................................................... 140 6.6.2 Event Inhibit/Enable - Zone Events ................................................................. 140 6.6.3 Event Inhibit - by Point Quality ........................................................................ 140 Event Storage ................................................................................................................. 141
6.2 6.3 6.4 6.5 6.6
6.7 7
Off-Normal Management ........................................................................................................ 142 7.1 Analogue Off-Normals .................................................................................................... 142

Page 7 of 215
1 Introduction
7.2 7.3 7.4 7.5 7.6
7.1.1 Off-Normals for Zone Alarms........................................................................... 142 7.1.2 Off-Normals for Flat Line Alarms ..................................................................... 142 Digital Off-Normals.......................................................................................................... 142 Off-Normals for Point Quality Alarms.............................................................................. 142 Off-Normals for Authorized Controls............................................................................... 142 Off-Normals for Annunciation Time Delay ...................................................................... 142 Off-Normal Inhibit............................................................................................................ 142 7.6.1 Off-Normal Inhibit/Enable - All Off-Normals .................................................... 143 7.6.2 Off-Normal Inhibit - by Point Quality................................................................ 143
Database and Supervisory ..................................................................................................... 144 8.1 Objects ............................................................................................................................ 144 8.1.1 Object Description ........................................................................................... 144 8.1.2 Object Name.................................................................................................... 144 8.1.3 Object/Attribute Identification (Pathname)....................................................... 144 Area, Alarm Group, Category, Alarm Priority.................................................................. 145 Persistence (Upload) ...................................................................................................... 145 Redundancy .................................................................................................................... 146 8.4.1 Redundant Objects.......................................................................................... 146 8.4.2 Object Synchronisation.................................................................................... 146 Networking ...................................................................................................................... 146 Database Organization ................................................................................................... 146 8.6.1 Database Name............................................................................................... 146 8.6.2 Multiple Databases .......................................................................................... 147 8.6.3 Database Distribution ...................................................................................... 147 Common Data ................................................................................................................. 147 8.7.1 System Constants ........................................................................................... 147 8.7.2 Inhibit Mask for Point Quality Flags................................................................. 148 8.7.3 Class Warmup Attribute Lists .......................................................................... 148 8.7.4 Message Translation of Text Keys .................................................................. 148 Supervisory ..................................................................................................................... 148 8.8.1 Process Monitor............................................................................................... 148 8.8.2 System Time and Time Synchronisation......................................................... 148
8.2 8.3 8.4
8.5 8.6
8.7
8.8
Calculations ............................................................................................................................. 149 9.1 9.2 Calculation Programs...................................................................................................... 149 Language Elements ........................................................................................................ 150 9.2.1 Use of Characters............................................................................................ 150 9.2.1.1 The Basic Line ................................................................................. 150 9.2.1.2 Keywords.......................................................................................... 150 9.2.1.3 Variable Names................................................................................ 150 9.2.1.4 Comments ........................................................................................ 150 9.2.2 Literals ............................................................................................................. 151 9.2.3 Data Types ...................................................................................................... 151 9.2.3.1 Elementary Data Types.................................................................... 151 9.2.3.2 User Defined Data Types................................................................. 152 9.2.4 Variable Definitions and SCADA Database Interface ..................................... 153 9.2.5 Statements....................................................................................................... 154 9.2.5.1 Assignment Statement ..................................................................... 154 9.2.5.2 IF Statement..................................................................................... 154 9.2.5.3 CASE Statement .............................................................................. 154 9.2.5.4 FOR Statement ................................................................................ 155 9.2.5.5 WHILE Statement ............................................................................ 155 9.2.5.6 REPEAT Statement ......................................................................... 155 9.2.5.7 Expressions...................................................................................... 155 9.2.6 User Defined Functions ................................................................................... 156 Built-in Functions ............................................................................................................ 157 9.3.1 Control Functions ............................................................................................ 159 Sequence Control Facilities ............................................................................................ 160 9.4.1 Sequence Control Program ............................................................................. 160 9.4.2 Operator Interface ........................................................................................... 160
Page 8 of 215
9.3 9.4
1 Introduction
9.4.2.1 Sequence Display ............................................................................ 160 9.4.2.2 Sequence Control Fascia................................................................. 161 9.4.3 Program Interface - Internal Data Elements.................................................... 162 9.4.4 Sequence Control Program Example.............................................................. 164 9.5 Calculations Configurator................................................................................................ 168 9.6 Calculations Linker.......................................................................................................... 168 9.6.1 Calculation Task Form..................................................................................... 169 9.6.1.1 Runtime Priority................................................................................ 169 9.6.1.2 Periodic Activation............................................................................ 169 9.6.1.3 Time Changes.................................................................................. 169 9.6.1.4 Triggered Activation ......................................................................... 170 9.6.1.5 Demand Activation ........................................................................... 170 9.6.1.6 Multiple Activations .......................................................................... 170 9.6.2 Calculation Executable Form........................................................................... 171 9.7 Calculations Runtime ...................................................................................................... 171 9.7.1 Overview of Program External Data Access and Quality Handling................. 173 9.7.2 Variable Initialization at Program Start ............................................................ 173 9.7.3 Variable Storage at Program End ................................................................... 174 9.7.4 Exception Handling.......................................................................................... 174 9.7.5 Quality Flags.................................................................................................... 174 9.7.6 Quality Flag Propagation (Calculations).......................................................... 175 9.8 Redundancy .................................................................................................................... 177 9.9 IEC 1131-3 Standard ...................................................................................................... 178 9.10 Period Type Calculations ................................................................................................ 180 9.10.1 Description....................................................................................................... 180 9.10.2 Quality Handling .............................................................................................. 181 9.10.3 Manual Override .............................................................................................. 181 9.10.4 Failures ............................................................................................................ 182 9.10.5 Database Install ............................................................................................... 182 9.10.6 Time Changes ................................................................................................. 182 9.10.7 Calculation Types ............................................................................................ 182 9.10.7.1 Sum .................................................................................................. 182 9.10.7.2 Average ............................................................................................ 182 9.10.7.3 Minimum and Date/Time of Minimum .............................................. 183 9.10.7.4 Maximum and Date/Time of Maximum ............................................ 183 9.10.7.5 Rate Of Change ............................................................................... 183 9.10.7.6 Digital - On Time .............................................................................. 183 9.10.7.7 Digital - Off Time .............................................................................. 183 9.10.7.8 Digital - Transition Count.................................................................. 184 10 History Storage and Retrieval................................................................................................ 185 10.1 History Storage ............................................................................................................... 185 10.1.1 Data Compression........................................................................................... 185 10.1.1.1 Delta Compression (with Optional Double Delta) ............................ 185 10.1.1.2 Fixed Sample Frequency ................................................................. 186 10.1.2 Disturbance Data Storage ............................................................................... 187 10.1.2.1 Disturbance Trigger Points............................................................... 187 10.1.2.2 Disturbance Occurrence Information ............................................... 188 10.1.3 Data Collection ................................................................................................ 188 10.1.3.1 Time Stamp ...................................................................................... 188 10.1.3.2 Missing Data..................................................................................... 188 10.1.3.3 RTU Time Tagged Data After a Communications Outage .............. 189 10.1.3.4 Retrospective History Processing After a Communications Outage (Optional) ....................................................................................................... 189 10.1.4 Quality Flag Propagation (History) .................................................................. 189 10.1.5 Redundancy and Catch-Up ............................................................................. 191 10.1.6 Time Clock Correction ..................................................................................... 192 10.1.7 Configuration ................................................................................................... 192 10.1.7.1 Object/Attribute Configuration .......................................................... 192 10.1.7.2 Adding/Deleting Objects and Attributes ........................................... 192 10.1.7.3 History System Parameters ............................................................. 192
I/A Series Intelligent SCADA System Page 9 of 215
1 Introduction
10.2 History Archive ................................................................................................................ 193 10.3 History Requests............................................................................................................. 193 10.3.1 Transforms....................................................................................................... 194 10.3.1.1 Quality Handling............................................................................... 196 10.3.1.2 Analogue - Sum ............................................................................... 196 10.3.1.3 Analogue - Average (Sample Frequency Method) .......................... 196 10.3.1.4 Analogue - Average (Linear Interpolation Method).......................... 196 10.3.1.5 Analogue - Standard Deviation ........................................................ 197 10.3.1.6 Analogue - Minimum ........................................................................ 197 10.3.1.7 Analogue - Maximum ....................................................................... 197 10.3.1.8 Analogue - Rate ............................................................................... 198 10.3.1.9 Analogue - Integral........................................................................... 198 10.3.1.10 Digital - On Time .............................................................................. 198 10.3.1.11 Digital - Off Time .............................................................................. 198 10.3.1.12 Digital - Transition Count.................................................................. 198 10.4 Distributed History Storage Space.................................................................................. 199 11 ODBC SQL Interface ............................................................................................................... 200 11.1 Office Connectivity .......................................................................................................... 200 11.2 Data Access .................................................................................................................... 200 11.3 SQL Query Statements................................................................................................... 201 11.3.1 Realtime Data Requests.................................................................................. 201 11.3.2 History Data Requests..................................................................................... 202 11.3.3 Event List Requests......................................................................................... 203 11.4 Security ......................................................................................................................... 203 11.5 Failures ......................................................................................................................... 204 11.6 Redundancy .................................................................................................................... 204 12 Applications............................................................................................................................. 204 12.1 Application Programming Interface (API) ....................................................................... 204 12.2 Application Management Support................................................................................... 205 12.3 Optional Applications ...................................................................................................... 205 12.3.1 Dynamic Network Colouring (DNC)................................................................. 205 12.3.1.1 Topology Configurator...................................................................... 206 12.3.1.2 Topology Processor ......................................................................... 207 12.3.1.3 HMI Displays .................................................................................... 208 13 Database Configurator ........................................................................................................... 209 13.1 Database Configuration .................................................................................................. 209 13.1.1 System Views .................................................................................................. 209 13.1.2 Database Forms .............................................................................................. 209 13.2 Install ......................................................................................................................... 209 13.2.1 Full Install......................................................................................................... 209 13.2.2 Incremental Install ........................................................................................... 210 13.3 Warmup ......................................................................................................................... 210 13.4 Merge ......................................................................................................................... 210 13.5 Migration ......................................................................................................................... 210 13.6 Program dbtable ............................................................................................................. 211 14 15 16 Performance and Capacity..................................................................................................... 212 Definitions and Abbreviations ............................................................................................... 214 References ............................................................................................................................... 215
Page 10 of 215
1 Introduction
INTRODUCTION
The purpose of this document is to describe the functionality of the iSCADA System. It contains an overview the system, a detailed description of each subsystem, and performance data for the system. The majority of this manual is concerned with describing the functionality of this software. The functionality specified in this document is only relevant to the standard software product. Any customization of the standard product is described in an independent document for a specific project, extracting information from this current document. This document is the basis for the design and implementation of the iSCADA System. System validation and verification is performed in accordance with Software Test Descriptions based on this Functional Specification. The intended audience for the iSCADA System Functional Specification is Foxboro Software Engineers maintaining and enhancing the iSCADA System, Foxboro customers and Foxboro marketing personnel interested in understanding the details of the iSCADA System. This document can be used to assess system suitability, propose modifications, and assist in tender preparation. Section 2 onwards of this document provides a detailed description of the iSCADA System functionality. Each section represents a uniquely identifiable part of the system. Statements are intended to provide a precise description, covering all aspects of the system functionality, and are used to verify conformance of the complete system. A separate section is devoted to system performance and capacity. DOCUMENTATION CONVENTIONS The following documentation conventions are utilized throughout this Manual: Syntax bold Example Warning (Solaris) (Windows NT/2000) Events List Window Enter button Delete Annotation option Database Name field dbtable cd /opt/scada/bin Sammi_license -w <RETURN> Press <F1> to continue. /<pointName>/cvq LNA_Dispatcher::instance(); void *upt1 Comments Information that the user should take particular notice of. Type of HMI station. The name of windows, buttons, fields, functions, etc.
italics
bold italics
Commands or input that must be entered by the user. The word or symbols between the < and > refer to a keyboard key, function. Also information that is to be inserted. Applications Programming Interface or program code.
<angled brackets>
Courier New font
HMI STATION CONVENTIONS An HMI Station can operate on either a Sun Solaris or Windows NT/2000 platform. Where there is a difference in operation it is identified as follows: (Solaris) for the HMI Station operating on a Sun Solaris platform. (Windows NT/2000) for the HMI Station operating on a Windows NT/2000 platform.
The manual describes the standard displays associated with the iSCADA System. The displays may vary depending on the amount of customisation employed to configure the system for individual user requirements. The display shown in this manual may be either from Windows NT/2000 or Solaris, in some cases there may be some small differences between the Windows NT/2000 and Solaris version.
Page 11 of 215
1 Introduction
DEFINITIONS AND ABBREVIATIONS Definitions and Abbreviations used throughout this document are listed in Section 15. REFERENCES Documents, manuals and standards referenced within this document are listed in Section 16.
1.1
iSCADA Master Station Overview
The following pages present the iSCADA Master Station Overview, and is the same as the PSS sheet.
Page 12 of 215
1 Introduction
I/A Series Intelligent SCADA SCADA Platform
Industry
Solutions
The I/A Series Intelligent SCADA (iSCADA) Platform is your complete integrated automation solution from the world-class leader in intelligent process management. Whether your enterprise manages the transmission or distribution of electricity, oil, gas, water, wastewater, or transportation of people and cargo, the iSCADA Platform provides a scalable, secure, and cost-effective operational solution. iSCADA presents an open user-friendly realtime data acquisition and supervisory control environment for your integrated enterprise. Standard interfaces provide low risk connectivity for industry-based high-level applications. Superior technology, reliability and flexibility put you in total control of your business.
Page 13 of 215
1 Introduction
The iSCADA Platform components are based on a proven, flexible distributed architecture, developed by the Foxboro Company with a history of 25 years of global SCADA project and product engineering. iSCADAs field proven reliability originates from design, maintenance and testing to strict standards. Foxboro TAC (Technical Assistance Centre) provides full field support, and Foxboros policy of ongoing development maintains currency with customer needs. The modularity and distributed architecture of the system components allow system capacity to grow with your business. The iSCADA System is designed to scale from a single workstation installation for a small project, to large high performance systems comprising many geographically distributed stations with remote backup. The database size can be from a few hundred
Operator Consoles
to over 50,000 points per domain. Multiple domains are supported (a domain corresponds to a single namespace in a network of physically connected systems). The latest Sun platforms (Solaris 8 with 64 bit kernel) and dual CPUs are supported, with system processing and applications running on the Sun hardware and Solaris Unix operating system technology. The Human Machine Interface (HMI) is also available on PC technology running Microsoft Windows NT/2000, with the same look and feel as on Sun hardware. The operating system is currently Solaris 2.8 for the Sun Unix machines, and Microsoft NT 4 or 2000 for PCs. Fault tolerant LAN networking is achieved by using Ethernet/IEEE 802.3, with all computers in the master station connected together using a dual Ethernet LAN. The TCP/IP protocol ensures transparent LAN network services.
Engineering
History and Events (archive)
SQL Access
Printer
Printer
Remote Operator Terminal
Redundant LAN
iSCADA Servers
Redundant Sub-LAN
Application Server Routers/ Firewalls Terminal Servers
CLS
Corporate LAN/WAN
GPS
Field Communication Communication Channels Channels

RTU50
Routed DNP Over TCP/IP Ethernet Ring
Remote Access Terminal
Optical RTU LAN OEM RTU via Open Protocol
RTU50
RTU50
RTU50
RTU10
RTU50 RTU50
PLC
IED
EFM
The iSCADA System components are distributed across computers, as and where needed, and arranged redundantly to support very high availability and performance, with no single point of failure. Redundant components may include:
Human Machine Interface (HMI) Front End Processor (FEP) Database Calculations History Communications
Page 14 of 215
1 Introduction
Networks and workstations
machine. A typical HMI console consists of one, two or three screens that provide a multiple X-window environment accessible by a single keyboard and mouse, with an audible alarm device. A Solaris HMI Station provides up to six operator consoles (one main workstation console and five X-Terminal positions). The location and look of windows on the HMI screen is fully configurable. A typical HMI screen includes: Display of date and time, console/user information, and an Audible Alarm icon. Buttons for invoking the system lists (alarms, events, off-normals and administrative tags), menus, administrative displays, and utilities. A window containing the three most recent unacknowledged alarms. A window containing user display/alarm group buttons. User configured displays invoked by the operator. System displays invoked by the operator. These include network information displays, communications information displays, printer summary, and console assignments.
State-of-the-art, realtime object distribution and management provide object level redundancy and load sharing in the master station. Communications with remote devices ensures the best possible service when disrupted by equipment failure or excessive communication error rates. The operational environment gives operate from anywhere network connectivity to the iSCADA database. The diagram shows the major units of the system built around a redundant Ethernet backbone LAN. Redundant CLS chassis are connected on a communications sub-LAN, keeping communications traffic off the main LAN. The iSCADA servers in this case are running all the iSCADA subsystems. This configuration is typical for systems of up to 50,000 points. As the systems scale up, subsystems are distributed by adding dedicated servers for tasks such as History, Calculations, Applications with API, and simple addition of more HMI Stations. The HMI Stations can be upgraded to applications workstation functionality allowing extra tasks such as, Calculation or Archive to be included, this makes use of idle CPU time typically observed in an HMI Station. Human Machine Interface (HMI) The Human Machine Interface (HMI) provides the operator interface and visualization tools of the system via single or multiple monitor displays. Fully configurable HMI screen and displays, provides realistic plant representation (dynamic and background). The operator can: Access data stored in the realtime and historical databases. Issue and monitor supervisory controls. Use the administrative displays to perform managerial functions. Activate the Database Configurator and other utilities.
The Solaris HMI Station provides dual language support for the operator's environment. The primary language is English, the alternative language is typically Chinese or Korean. Multi domain HMI support provides: Ability to access and store iSCADA data, and perform supervisory controls, across domains from a single display. Integrated events. Integrated alarm indications (the Alarm List is per domain).
Data Visualization Realtime and historical data is represented by specialized dynamic foreground components on a wide range of graphic displays. Runtime annotation characters indicate the quality of point current values. Foreground components include: Numbers and text. Bar graphs and pie charts. Meters and gauges. Pushbuttons. Sliders. GIF and X-bitmap images. Dynamic object colouring. Object x/y animation. Shrink and grow object animation. Historical value.
Page 15 of 215
The "operate from anywhere" architecture supports remote modem access by Windows NT/2000 HMI Stations. A web browser operator interface is also available. Each remote HMI has the same HMI functions as those at the iSCADA Master Station. Security mechanisms recognize authorized users by name and password. System access and capabilities are limited by class of user (such as operator or engineer), and also limited to their own assigned areas of responsibility. Areas of responsibility are associated with operator login but can be restricted per
1 Introduction
Historical single and multiple pen trends. Historical tables. Historical x/y plots.
Print a displays foreground log. Incident and periodic event logging. Reports.
Complexity can be managed by the use of: Layering. Panning. Zooming. De-cluttering.
Other Features Other features in the HMI include: System list filtering. Event list viewing of archived events. Event annotation. Selection of database for data access, start/stop database. Change database server, change domain. Operator entered window notes. Communications manual in/out of service. RTU in/out of scan, on/off test mode. History data editing (of online history). History replay. A time range of history and event data can be replayed on point displays and the Event List, forwards or backwards, running at normal or fast speeds, single stepping and stop. Flexible date format. One display can be used for many similar say stations, by using Point name references containing a station name (foreground key concatenation).
Display Navigation The operator is able to navigate to displays using: Display selection from dynamic objects. Quick display call-up from point value/alarm entry. Built-in navigational links between displays.
Control Presentation Supervisory control (trip/close, setpoint, etc) is managed directly from the observed display by presentation of all relevant information. This provides: Control access from any point value. Positive control reserve indication. Two-step control actions. Associated point value and quality status display. Dynamically updated system lists.
Front End Processor (FEP) The Front End Processor (FEP) is the telemetry manager of the system. Redundant FEPs, communication equipment and lines, can be configured and managed. The FEP is responsible for maintaining optimal data communications with all remote devices, particularly in the event of RTU (Remote Terminal Unit) port failure, line failure, hardware failure, and failures due to excessive error rates. The FEP retrieves realtime data from, and issues securely managed supervisory controls to remote devices, using its protocol independent communication interface. It can communicate with many redundantly arranged remote devices at any one time. Physical communication interfaces can be: Communication Line Servers (CLS). Standard terminal servers (e.g. with redundant multiple RS-232 telemetry connections). Direct TCP/IP connections using SCADA protocols (e.g. DNP over TCP/IP). FEP workstation integral RS-232 ports.
Administrative Functions Selecting a point on any window pops up a palette allowing access to administrative control functions, including: Change alarm limits and other alarm parameters. A variety of inhibit actions for alarms, events and off-normals. Manual change. Substitution of an alternate point source, say for a point with a faulty or suspect input. Point in/out of scan, on/off test mode. Demand scan. Easy assignment of point to an Operator Assignable Trend Display. Set/clear operator tags, and entry of tag notes. Invoke point information display.
Logging Printing features in the HMI include the following. Output can be directed either to the local printer or a printer on the network. If the main printer fails, runs out of paper, or is taken offline, then output is directed to the backup printer. Print screen, print window.
Protocols currently supported by the FEP include (Foxboro track and contribute to a variety of the open protocol user groups and committees):
Page 16 of 215
1 Introduction
DNP3 IEC 60870-5-101 Conitel (2025, 2020, and C300) Modbus
The FEP co-ordinates the following data communications, using standard protocol facilities: Scanning of field devices periodically, continuously, or on demand. Millisecond resolution time stamped SOEs, events and other time tagged data from remote devices. Receipt of unsolicited DNP3 messages containing field data. Supervisory control requests to field devices and feedback monitoring. Check before execute output commands. Millisecond resolution time synchronization of remote devices and master stations. DNP3 file transfer to and from the RTU.
incoming raw data and updating of realtime iSCADA objects, typically analogue, digital and accumulator points. Object data is published to services including alarms, events, HMI, history and application interfaces. Some features provided are: 64 data quality flags per point, to indicate software detected and manually entered conditions. ADC/Engineering limit checks. Exponential filtering. Accumulator processing and totalisation.
The Alarm system detects and annunciates points that have entered into or exited from abnormal conditions. The operator is kept informed of alarm conditions by: An audible alarm. The Alarm List, containing the current alarms. A list of the three most recent unacknowledged alarms. Flashing of the point on all displays. Associated alarm group buttons changing colour/flashing.
The FEP performs the following communications management services: Health monitoring of communication routes (path to remote device), including those that have failed or are currently not in use. Calculation of line usage and error statistics for diagnostic and operational review. Manually initiated failover and failback. Automatic failover when communications deteriorate. Automatic failback when health of a higher priority communication route improves. Failover by communication route rather than whole communication line, where configuration allows. Dialup communication links. For the DNP3 protocol, a PC running TOOL (or RTV) can be connected, remotely via the master station, to an RTU for diagnosis and programming.
Features provided for analogue points: High, critical high, low, critical low analogue alarm limits with deadbands. Up to 127 severity zones with deadbands. Better and worse alarm zone tracking. Generation of associated events and offnormals. Flat line detection.
For digital points: Alarm when the digital point enters/exits particular states (as configured).
For all points: Analogue and digital fleeting change filtering, by alarm annunciation time delay. Eight alarm priorities determine the colour of the alarm list entry and the audible alarm tone. Alarm List can be sorted by alarm priority and alarm time. Alarm List can be filtered using several point classifications, alarm priority, and time range. Audible annunciation. Audible and visual acknowledgement. Alarm List line and page-based acknowledgment. Automatic alarm acknowledgement and deletion. Manual and automatic inhibit actions for alarms, events and off-normals.
The optional Communication Line Server (CLS) (reference: PSS 21H-8D2 B4), is a Foxboro device tightly integrated with the FEP software, that provides features not available in commercial terminal servers. These include: Redundant LAN connections. Physical line failover switching. Isochronous protocols. Direct GPS interface. High accuracy (millisecond) synchronization of remote devices. Integrated V.23/Bell 202 modems. Industrial hardened technology.
time
Core SCADA Core SCADA provides the core processing of

Page 17 of 215
1 Introduction
Database The iSCADA System uses the commercially available Versant Object Oriented Database Management System (OODBMS) to manage all objects instantiated in memory and on disc for read, write, install, redundancy, and data persistence. Typical system objects are: Points. Scanned devices (e.g. RTUs). Communication channels. Scan rates. iSCADA stations. Common data that describes the general characteristics of the whole system.
A sequence control program (for say emergency shutdown, plant startup) can be written. It consists of a number of steps, which include arithmetic calculations and/or supervisory controls. A Sequence Control Fascia allows the operator to control the sequence, and a user configured sequence display shows the status of the sequence graphically. Period Type Calculations Period Type Calculations are time-based functions of single variables running in real time. Facilities include: Calculations for analogue sum, average, minimum/maximum, rate of change, and digital on/off time, transition count. Result updated continuously (e.g. the current average of a point value so far this hour), or result updated at period end (e.g. the average of a point value for the previous hour).
Points represent objects such as field devices, calculation results, and manual points. Each point is associated with an operational area, an alarm group and one or more categories, for the purpose of access permission and system list filtering. The distributed realtime database provides intrinsic fault tolerance by its precedence facility, which permits redundant objects on different stations. The highest precedence object is presented to clients. Multiple concurrent databases are supported, allowing multiple systems to be run, for realtime operation, study/simulation, testing and database development. Calculations There are two calculation facilities: Calculation Programs written by the user. Period Type Calculations configured by the user.
History Extensive historical data and event log storage facilities are provided for post-incident, accounting and statistical analysis. Distributed redundant storage of iSCADA data samples, point attributes, and events, is maintained typically for one year on-line. Realtime data samples of configured point attributes are recorded on a change exception basis for later retrieval. Data samples arriving late or out of sequence due to communications failures are merged with the stored data sequence for that point. Old data can be automatically compressed to optimize storage space. Disturbance triggers can be assigned to prevent compression of data associated with a plant disturbance, allowing accurate disturbance analysis. Centralized archival and retrieval, manages historical data in periodic archive files on DVD RAM. Event data is also similarly managed in periodic archive files on DVD RAM. Retrieval of history data from distributed online storage and any currently mounted archive files, is seamless. History transform functions enable time functions of single variables to be performed on retrieved historical data (e.g. the average of a point value over an hour). ODBC SQL Interface The ODBC Structured Query Language (SQL) Interface enables Open DataBase Connectivity to enterprise databases for corporate data exchange and personal computer desktop
Page 18 of 215
Calculations Programs Calculation Programs are written with the iSCADA comprehensive calculation and sequence control facilities, based on IEC 11313 structured text. The same program can be linked many times to form calculation executables. Thus a generic program can be written for say monitoring and controlling a boiler, which is then linked for each specific boiler. Programs can also be prepared away from the system then imported. Digital state-change triggering, periodic execution or operator request can initiate calculation execution. When a calculation executable is initiated, object data is read, the calculations and operations are performed, and any results are written back to database objects.
1 Introduction
applications access. It provides an information service to ODBC compliant third party applications such as Microsoft Excel and Microsoft Access. Data is served from the realtime database, history and events, using a defined subset of the ANSI standard SQL query statements. Applications Applications augment the basic functionality of the iSCADA System. They can be supplied by Foxboro or written by customers. Application Programming Interface (API) The Application Programming Interface (API) provides the user with two interfaces to the iSCADA System for integrating OEM process applications and user-developed application packages: The Object Interface Library (OIL) provides a high-level programming interface in the C language. Functions include fetch, store and command. The Database API (DAPI) provides a lower level interface to data and call functions within the iSCADA System, in the C++ language. The RTU File Transfer API, for the DNP3 protocol, provides C++ language interface functions for file transfer to and from an RTU.
Other applications on request.
Supervisory The iSCADA process monitor runs in each Solaris station to supervise and report on the state of the iSCADA subsystems running in each machine. Network Time Protocol (NTP) is used to synchronize time between the NTP time master and all other LAN connected Solaris stations. Daylight saving time changes are managed. Windows NT/2000 based stations are synchronized using Microsoft NTP or equivalent resources for Windows NT/2000. Database Configurator The iSCADA database and calculation programs are configured using the Database Configurator. Online incremental install of points (not FEP attributes) and history is provided. Configuration data can be imported and exported in text format. Diagnostics The system comes equipped with a range of diagnostic facilities to enable straightforward maintenance: Station startup tests for Sun computer hardware and software. Online system monitoring - for CPU, memory and LAN network statistics, RTU communications, printers and video copiers in/out service information, the Event List for system generated events for communication errors, equipment and software failures, etc. Off-line diagnostics - for iSCADA hardware.
Operations between iSCADA and application processes are co-ordinated to ensure smooth running of the system. An Applications Management display allows application processes to be monitored and controlled. Foxboro Supplied Optional Applications Dynamic Network Colouring (DNC) visually presents network connectivity, by dynamically colouring network segments on line diagrams to reflect the realtime state of the network. Each source spreads a different colour, indicating which source a segment is connected to. Real Time Interface (CES Distribution Management System).
Software Upgrades An auto installation utility is provided for easy software upgrades, when software enhancements and maintenance updates are needed.
Page 19 of 215
2 HMI
HMI
The HMI allows the operator to access data stored in the realtime and historical databases, manage alarms, events and off-normals, perform supervisory controls, replay history and event data, and access the Database Configurator and tools. Printing facilities include print screen/window, display foreground log, event logging (incident and periodic), and reports. Other features in the HMI include archive and display of event information, selection of database for data access, and operator entered text messages. A security mechanism is provided, that limits the access and capabilities available to a user. Each Solaris HMI Station provides up to six operator consoles (operator/user positions). The main console is at the workstation consisting of one, two or three screens, one QWERTY keyboard, one mouse, and an audible alarm device. The other consoles are X-Terminals. Each Windows NT/2000 HMI Station provides one operator console. The HMI is based on the SAMMI full graphics package that supports panning, zooming, de-clutter and multiple X-window based displays. The location and look of windows on the HMI screen can be configured. The HMI accesses database information and can display it in many different ways. Windows include the user configured displays, Alarms, Events, Off-Normal and Administrative Tags lists (with filter options), Network information displays, Communications information displays, Printer Summary, and Console Assignments.
2.1
The HMI Station
A domain (HMI domain) consists of a logical group of iSCADA stations, which share a common iSCADA database interconnected on a Local Area Network. All iSCADA stations that run the iSCADA database application are Sun Solaris machines, these machines can also run the HMI software, known as Database HMI Stations. Solaris and Windows NT/2000 HMI Stations can be used as Databaseless HMI Stations, these do not run the iSCADA database application. The HMI Station can be: A Solaris Database HMI Station (e.g. HMI/FEP/Core SCADA station). A Solaris Databaseless HMI Station. A Windows NT/2000 HMI Station (Databaseless).
Most functionality applies to each platform except where specifically noted.
2.1.1
Solaris Database HMI Station
The Solaris Database HMI Station platform is a Sun computer running the Solaris Operating System with the SAMMI full graphics GUI package, and an iSCADA database. Each Solaris HMI Station provides up to six operator consoles (operator/user positions). The main console is at the workstation consisting of one, two or three screens, one QWERTY keyboard, one mouse, and an audible alarm device. The other consoles are X-Terminals. The station may be used as a database server station (i.e. where the currently selected default database for another stations console resides). A typical Sun platform is: Workstation Memory Hard Disc Sun Solaris 2.8 operating system compatible 400Mhz workstation. 500 MB (dependant on database size, internationalization, etc) 4 GB
Note: An International HMI Station (i.e. capable of operating in an alternative language) requires approximately four times the memory size required by a standard HMI Station. The memory increase is mainly due to the language translation dictionaries.
2.1.2
Solaris Databaseless HMI Station
The Solaris Databaseless HMI Station platform is a Sun computer running the Solaris Operating System with the SAMMI full graphics GUI package, but no iSCADA database. The database is not
2 HMI
required in providing the HMI functionality, the Solaris Databaseless HMI Station connects to a database server directly via the LAN or WAN, instead. Thus the Solaris Databaseless HMI Station can be a local operator station or a remote operator station. Each Solaris HMI Station provides up to six operator consoles (as per Section 2.1.1). The Solaris Databaseless HMI Station is fully independent of other Databaseless HMI Stations. It provides the same HMI functionality as a Database HMI Station. The look and feel of the windows and their operations are very similar. The Solaris Databaseless HMI Station has the following additional features: Automatic changeover on fail of server. Automatic changeover on network or connection failure.
The Solaris Databaseless HMI Station allows the total number of databases to be reduced, and avoids the need to run the iSCADA database application on that station. The Databaseless HMI Station does not have the SCADA, Versant, or OSE packages installed.
2.1.3
Windows NT/2000 HMI Station (Databaseless)
The Windows NT/2000 HMI Station platform is a PC running the Windows NT/2000 Operating System with the SAMMI full graphics GUI package. It does not contain an iSCADA database, it connects to a database server directly via the LAN, WAN, or via the dial-up modem networking feature of Windows NT/2000. Thus the Windows NT/2000 HMI Station can be a local operator station or a remote operator station. Each Windows NT/2000 HMI Station provides one operator console (operator/user position). The Windows NT/2000 HMI Station provides the same HMI functionality as a Database HMI Station. The look and feel of the windows and their operations are very similar. The Windows NT/2000 HMI Station has the same feature set as the Solaris Databaseless HMI Station. The recommended PC platform is: Operating System Microsoft Windows NT 4.0 with Service Pack 5 or above, or Microsoft Windows 2000 including service pack 3 or above. Processor Intel Pentium III 1 GHz Memory 256 MB Hard Disc 4 GB (with 1 GB free) Video Card 32 MB, 1280x1024 resolution, 256 colours or better Screen 19 inch, 1280x1024 resolution Keyboard 101 key (standard) Mouse 2-button (3-button mouse is recommended) Sound 16 bit Network Card 10/100 MB supporting TCP/IP
Optional items are: An additional 10/100 MB network card is required to support network redundancy. Modem with the speed at least 9600 baud to support remote access. A special graphics card that supports multiple screens for multi-head system.
The time on a Windows NT/2000 HMI Station is normally synchronized with the database server station.
2.1.4 iSCADA WebConnect (iWeb)

iSCADA WebConnect (iWeb) provides a web browser operator interface for the iSCADA Platform. The web browser interface enables the user to remotely (via dial-up or WAN) or locally (via LAN) access and operate the iSCADA system from a PC using the same graphical user interface as an HMI Station. A simple web based screen allows the user to call up, connect, and utilize the iSCADA graphical user interface, with a Java enabled browser such as Internet Explorer 5.5. No other special software or license other than the browser license is required on the user PC.
Page 21 of 215
2 HMI
Up to 6 sessions are allowed per Unix server, depending on memory and disk capacity. After 30 minutes of inactivity on the user PC, the session is automatically logged off.
2.1.5
Domain Support
Each domain has its own SCADA database that is not shared between domains. Gateways (or routers) are used to connect the domains (WAN) to prevent unnecessary network traffic. The recommended network connection between domains is by redundant 2 Mbps links. An HMI Station is to be able to access the SCADA database in any configured domain. This allows an HMI to access and store SCADA data, and perform supervisory controls, across domains. Any type of HMI Station in a domain can access any other domain. Additionally, a stand-alone Solaris Databaseless or Windows NT/2000 HMI Station, not belonging to a domain (i.e. domainless), can access any domain. Note that HMI domain support is not the same as SCADA database domain support (future). An HMI domain can support a maximum of 32 HMI Stations. The HMI Station accesses data from the currently selected domain and server. By not specifying a domain name in the display objects configuration, displays access data from the currently selected domain. By specifying a domain name for display objects, data is accessed from that domain. Different objects on the same display can specify different domains. If the realtime database in the domain cannot be accessed (e.g. it is not running online in the chosen station/server, the WAN has failed, etc) then this is indicated, for example, by point values with an ER modifier, a blank Alarm List, a blank Control Window domain field. The HMI Station provides limited merging of data from multiple domains as follows: 1. For alarms, the following can be merged: The 3-Most Recent Alarms Window. The HMI Command Window Audible Alarm button and the Alarm List button. The associated Control Window alarm group buttons. The audible alarm.
Note that the alarm lists from each domain cannot be merged into one domain wide alarm list. 2. For events, the following can be merged: The Event List.
The domains to be merged are specified by a domain mask parameter, which is defined in a system startup file. The domain mask parameter can be changed online by SAMMI command entry or by command from a program.
2.2
2.2.1
HMI Data Access Failure and Failover

Server Failure
There are several types of HMI Station. They are all affected differently when access to the current server database fails due to server software/hardware failure. For hardware failure, the HMI retries the connection for 5 seconds before deciding to failover. 1. Combined Database HMI/FEP/Core SCADA Station - if the database fails (or is unloaded), the displays lose dynamic data. 2. Database HMI Only Station (i.e. its local database does not contain points) - if the database in the source station fails (or is unloaded) or its hardware fails, the displays do not lose dynamic data. Because the HMI always gets the highest precedence data in the system via its own database (assuming the points have redundant copies). 3. Solaris Databaseless HMI Station, Windows NT/2000 HMI Station, and Xterminal - if the database in the server fails (or is unloaded), the displays lose dynamic data. If the server station shuts down or fails, then the HMI selects the first available station in the server list (regardless of online database) of the same domain.
Page 22 of 215
2 HMI
If one of the dual LAN connections to the current server station is disconnected, the HMI fails over to the next available network and server combination. This may be to the same server but the other network connection, depending on the server list. If there is no available server to fail over to, then the HMI periodically (5 secs) tries to re-establish connection to a server in the list of the same domain in a round-robin fashion. The HMI can be configured to fail to another domain, if desired.
2.2.2
HMI Data Access Failover
HMI Data Access Failover is an option that allows all HMI types to maintain access to realtime data, on a per screen basis. It is enabled per screen in a system startup file. HMI Data Access Failover is beneficial for operator positions. For an engineer wishing to control a selected station, it is not enabled. If HMI Data Access Failover is enabled, and access to the current database fails (for any reason), the HMI automatically connects to another station of the same domain in the server list that has a default online database. Normally this is the same database as the current server, but this is not enforced. Thus the HMI screen continues to display dynamic data. The HMI cycles through the server list starting from the current server position. If no default online database is found it does not failover unless a hardware failure has occurred, then it selects the first available station of the same domain in the server list (Section 2.2.1). The following summarizes the types of HMI and effect of HMI Data Access Failover: 1. Combined Database HMI/FEP/Core SCADA Station - with HMI Data Access Failover, if the database fails (or is unloaded), the HMI connects to another server. 2. Database HMI Only Station (i.e. does not contain points) - with HMI Data Access Failover, if the database fails (or is unloaded), the HMI connects to another server. With HMI Data Access Failover, a Database HMI Only station can be replaced with a Solaris Databaseless HMI Station, and still provide the same data access integrity when the source database fails. 3. Solaris Databaseless HMI Station, Windows NT/2000 HMI Station, and Xterminal - with HMI Data Access Failover, if the server database fails (or is unloaded) or its hardware fails, the HMI connects to another server. The HMI/Xterminal is still logged onto the station that the user manually selected, even though data access may have failed over. After several HMI Data Access failovers, all screens could end up on the same server. This does not necessarily degrade the performance (because data still comes from primary objects regardless of which station the HMI is connected to). A server should be able to handle at least 3 clients without showing significant/observable performance degradation. There is no automatic failback, which could be disruptive to the user. The HMI screens can be manually re-connected at some convenient time (i.e. when the operator is not in the middle of a control operation, data entry, etc). The user is still able to manually connect to any station in the server list, regardless of default online database (refer Section 2.12.5). HMI Data Access Failover does not generate an event. During failover, the screen may not be updated with live data, for approximately 2-3 seconds. The modifier ER may be shown. Some operations may be disrupted, e.g. list filtering stays as selected but a currently displayed list may go back to page 1.
2.3
System Security
A security mechanism is provided that limits the access and capabilities through recognition of authorized users (by name and password), user class (i.e. category of user, such as operator or engineer), display access security levels (to restrict access to display) and iSCADA system capability (to restrict use of a function).
Page 23 of 215
2 HMI
2.3.1
Authorized User
An authorized user is recognized through a logon sequence at a console. A User Authorization File specifies all authorized users. Each authorized user has an associated security class, password, keyboard binding file, file of display commands to execute at logon, logon/logoff time, inactive period and assigned user classes. For all user actions, an operator action event is generated, with the user name appended.
2.3.2
User Classes
A user class may be considered a category of user on the system. A given user may belong to more than one user class. Each user class nominates: Area assignment (areas of responsibility), on a system wide basis. Each database point is assigned to an area. Alarms that belong to the assigned areas are directed to, and can be acknowledged from, the user's console. On displays, all points are visible but actions are rejected on points that do not belong to the assigned areas. The Events, Alarm, Off-Normal and Administrative Tags Lists, only show entries for points in the assigned areas. A set of area masks for particular fascias, to restrict controls and operations the user can carry out. A list of administrative functions the user can carry out (refer Section 2.4.6). The button is insensitive and ghosted if the function is not allowed. A list of general system functions the user can carry out (refer Section 2.4.5). The button is insensitive and ghosted if the function is not allowed. A set of commands to be executed when the user logs in and another when the user logs out. A set of commands to be executed when the user class is entered and another when it is exited.
2.3.3
Display Access Security Levels
SAMMI provides a security class facility that can be used to restrict users from accessing certain displays of data depending on their security class. A display can be assigned a security level. In addition, display components (e.g. a meter) can be assigned a security level. System wide, eight unique levels are provided. The security levels defined in the user security class are compared with the security level on the display or with the security level of display components: Read and Write - allows call up in the case of a display, and display/actions to be performed on display components. Read only - allows call up in the case of a display, and viewing of display components. Actions cannot be performed on display components. Not Available - inhibits call up in the case of a display, and inhibits viewing of display components.
This facility may be used independently of the SCADA system capability to control operator action.
2.3.4
SCADA System Capability
The SCADA System capability can be limited by area. Each function is assigned an area mask. A check is made that the points area has the function permitted: Function Permitted - icon or button for this function is made sensitive. Function Not Permitted - icon or button for this function is made insensitive. The function cannot be selected. A different texture can be used to alert the insensitivity.
2.4
HMI Console
The standard system HMI screen has 3 fixed windows, the Command Window, Control Window and 3Most Recent Alarms Window. They cannot be closed or moved. The rest of the screen is available for user and system displays. The location and look of all windows is configurable, they can access
2 HMI
database information and display it in many different ways. The HMI screen can contain multiple windows that can overlap. Each window contains a single display consisting of both fixed (background) and variable (foreground) information. The background is output once when that display is invoked. The foreground consists of objects that are values or symbols associated with data in the database (e.g. database points), refreshed nominally every 1-second, depending on the type of information.
Command Window
User Button 1 User Button 3 LnaSyd Points List
User Button 2 User Button 4 SPM Monitor SPM Trend 2 User Button 10 User Button 12 Analogue Types D32S Analogue Tabular D32S Arrays User Button 20 User Button 22 User Button 24
alarms:
24 24 24 25 24 24 24 24 24 24 24 24 24 25 24 24 24 24 24 24 24 24 May May May May May May May May May May May May May May May May May May May May May May 02:10:32 03:19:37 03:19:37 16:55:42 03:19:38 03:19:39 03:19:39 23:14:40 14:11:54 03:19:41 23:51:24 13:19:37 19:09:46 02:34:17 18:09:46 17:44:33 17:44:34 17:44:34 23:19:39 17:44:35 17:44:35 17:44:36 11KV TRANSFORMER A CURRENT ISOLATOR FDR 245 RTU #5 11KV TRANSFORMER B CURRENT ISOLATOR FDR 246 33KV NO 6 CCT BREAKER GEN A SEAL OIL INLET 11KV TRANSFORMER A TEMP 11KV TRANSFORMER B TEMP GEN D SEAL OIL INLET FAN B HOUSING FIRE COMMS LINE #3 GEN C SEAL OIL INLET 11KV TRANSFORMER D CURRENT COMMS LINE #4 FAN A HOUSING FIRE 11KV NO 1 CCT BREAKER 11KV NO 2 CCT BREAKER 11KV TRANSFORMER D TEMP 11KV TRANSFORMER C TEMP ISOLATOR FDR 303 GEN B SEAL OIL INLET HIGH ALARM OPEN FAILED HIGH ALARM OPEN INVALID LOW ALARM HIGH ALARM HIGH EXIT CRIT LOW EXIT OUT FAILED LOW EXIT CRITICAL HIGH RECOVERED OPEN OPEN OPEN CRIT HIGH EXIT HIGH ALARM OPEN CRITICAL LOW 280.0 AMPS ALM 1 ALM ALM BAD ALM ALM ALM 1 WRS 6 RTN BTR 12 RTN ALM RTN WRS 25 RTN ALM BAD ALM BTR 17 BTR 2 ALM ALM 5 Top
SPM Trend 1
277.4 AMPS
Filter User
Button 9
31.9 116.0 78.3 18.9
KPA DEGC DEGC KPA
AcknowUser ledge Button

11
Delete D32S
RTU
42.6 KPA 336.7 AMPS
Page D32S Mode Status

Tabular
240.2 DEGC 105.8 DEGC 15.1 KPA
Line Mode
D32S MCD Tabular User 19 User Button 21
Bottom Button
14
Unacknowledged Alarms
24 May 24 May 24 May
02:10:32 03:19:37 03:19:37
ISOLATOR FDR 245 11KV TRANSFORMER D TEMP OPSTN1 PRINTER
OPEN CRITICAL HIGH FAILED
327.5 DEGC
Raise Lower ALM Ack WRS 17 Ack ALM Ack
User Button 23
User and System Display Area
3-Most Recent Alarms Window
Control Window
Selecting an object invokes a special type of display (palette), containing a selection of applicable functions. The palette has the text pl_ in the display identification. Selecting some functions invoke another special type of display (fascia), containing the means to set the parameters of the function. The fascia has the text fs_ in the display identification. When more than one fascia is on display, the fascias are stacked. Mouse The mouse can have either two or three buttons. If only two buttons, the system may be configured so that clicking both simultaneously achieves the same as clicking the middle button on a three-button mouse. The function of each button depends on the type of object selected. The left button is the select button, used to select an object on the screen. This includes selecting an active window, activating (pushing) a software button, selecting a point display, and selecting a system list entry. When the selection causes a palette/fascia/window to be invoked, it is displayed near the click position. The right button is the menu button. When used on a window it pops up a menu associated with the window, if configured. The options on the menu can be the same as the menu bar that appears on the top of the window. When used on an entry text field it pops up a list that contains all the valid items. Selecting an item from the list enters the item into the text field. If a pop-up menu is not configured,
2 HMI
then No Menu is displayed. The middle button is the adjust button. Clicking on a trend chart's Y-axis invokes the zoom control panel.
2.4.1
Command Window
The Command Window provides access to the standard iSCADA Displays, including Alarms, Events, Off-Normals, Administrative Tags, system, and administration displays. It is normally configured so that other windows cannot be moved on top of it (Solaris). The Command Window contains the following elements:
11 12 13 14 15 16 17 1 4 5 6 8
10
1. The currently selected default database for the console. 2. The domain name. 3. The name of the HMI Station that the user is logged onto. 4. (Solaris Databaseless and Windows NT/2000) The name of the Solaris station where the currently selected default database for the console resides (database server station). 5. The current SAMMI logon user name. 6. The current SAMMI logon user class. To change to another user class, click on this field, and select an entry from the list of valid user classes that is presented. 7. The console number. There may be more than one console supported by a single HMI Station. The number indicates which console the current logon is on. For Windows NT/2000, there is only 1 console supported by each Windows NT/2000 HMI Station. 8. The system date/time. Updated every second. 9. The SAMMI command entry field provides facilities for SAMMI command entry. If this function is available to the user, SAMMI commands can be entered by clicking on this field, the field becomes active and responds to any SAMMI commands entered via the keyboard. If at any time during the course of normal system operation, an error occurs within SAMMI, a corresponding error message is reported directly above this field. 10. SAMMIs display cache memory buffer can be purged on demand by clicking on the iSCADA logo. This action is only necessary when a display has been modified with the SAMMI Display Editor (refer SAMMI Format Editor manual). 11. Audible Alarm button (Section 2.4.1.1). 12. Alarm List button (Section 2.6.1). One or more alarm groups may be assigned via the Alarm Group Button Edit function (Section 2.4.6) (configurable on a console basis). When there are any alarms in the operators areas of responsibility, the Alarm List button is coloured/flashing using the same scheme as the Control Window Alarm Group Buttons (refer Section 2.4.3). 13. Event List button (Section 2.6.2). 14. Off-Normal List button (Section 2.6.3). 15. Administrative Tags List button (Section 2.6.4). 16. General System Displays button (Section 2.4.4.2). 17. Administrative Displays (Tool Box) button (Section 2.4.6).
2 HMI
2.4.1.1
Audible Alarm
The audible alarm is sounded, and the Audible Alarm button starts flashing, when an alarm is annunciated (refer Section 5.4). The highest alarm priority point determines the tone of the audible alarm. Depending on the hardware configuration the tone type may be either a simple beep for all alarm priorities, or a recording of some appropriate sound (e.g. bell ringing) that can be different for each alarm priority. The tone type is configured via the Set Audible Alarm button (refer Section 2.4.6 Set Audible Alarm). The audible alarm on a HMI console is silenced if no one is logged on to the HMI console. This does not cause the audible alarm to be acknowledged. When an operator logs on at any HMI console (eg after a second HMI console is started), the audible alarm is sounded and the Audible Alarm button starts flashing, if no one has acknowledged the audible alarm for the operators areas of responsibility. 2.4.1.1.1 Audible Acknowledge
Clicking the Audible Alarm button silences the audible alarm on this station. The Audible Alarm button stops flashing. An operator action event is not generated. The audible acknowledge is also applied to other HMI stations. However only areas being audible acknowledged in this station are audible acknowledged on the other HMI stations. If another HMI station is sounding an audible alarm due to areas that are not being audible acknowledged in this station, then the audible is not silenced. This may also cause the audible tone to change on other HMI stations, if the audible acknowledge has silenced higher priority alarms. 2.4.1.1.2 Audible Silencing, Acknowledge, and Automatic Logoff Options
The following options are defined in a system startup file, on a per HMI console basis: 1. Silence the audible alarm on a HMI console if there are no unacknowledged alarms. This does not cause the audible alarm to be acknowledged, and therefore does not stop the Audible Alarm button flashing. This is disabled by default. 2. Acknowledge the audible alarm on a HMI console if there are no unacknowledged alarms. This has the same effect as clicking the Audible Alarm button (see above), where the Audible Alarm button stops flashing and the audible acknowledge is also applied to other HMI stations. This is disabled by default. 3. Automatically logoff the user if there is no SAMMI user-activity performed (e.g. open SAMMI window, push SAMMI button, etc) for a configured inactivity period, outside the normal working day (optional). The inactivity period and normal working day are common to all the HMI sessions hosted in that station. The audible alarm is silenced. This does not cause the audible alarm to be acknowledged. This is disabled by default. Automatic logoff is also used when it is required to silence the audible alarm on an HMI console if there has been no activity on the HMI console for a defined period of time. 2.4.1.1.3 Remote Audible Alarm
Refer Section 2.15 (HMI Background Jobs).
2.4.2
14
3-Most Recent Alarms Window

Unacknowledged Alarms
24 May 24 May 24 May
02:10:32 03:19:37 03:19:37
ISOLATOR FDR 245 11KV TRANSFORMER D TEMP OPSTN1 PRINTER
OPEN CRITICAL HIGH FAILED
327.5 DEGC
Raise Lower ALM Ack Ack WRS 17 Ack ALM
The 3-Most Recent Alarms Window consists of the three latest unacknowledged alarms for the operators areas of responsibility. There is only one entry for a given point. It is sorted on last alarm annunciation time. The lines are formatted the same as for the Alarm Window, except there is no flashing. The window also shows the total number of unacknowledged alarms, has a button per line for alarm acknowledgment, and buttons to raise/lower the windows stacking order on the screen.
Page 27 of 215
2 HMI
2.4.3
Control Window
The Control Window (shown in Section 2.4) contains twenty-four buttons that can be configured to invoke any display. One or more alarm groups may be assigned to each button via the Alarm Group Button Edit function (Section 2.4.6) (configurable on a console basis). The Control Window Alarm Group buttons are configurable to function in one of the following three ways. All buttons operate the same. The option is set in a system startup file, on a per HMI station basis. The default is option 1. 1. Option 1 - When there are any alarms in an alarm group, the associated Control Window Alarm Group button are coloured/flashing as follows: If there are any unacknowledged alarms in any alarm group assigned to the button, the button flashes in the highest priority alarm colour. Otherwise, if there are any acknowledged alarms in any alarm group assigned to the button, the button is steady in the highest priority alarm colour. Otherwise, the button is uncoloured. The button colours are factory preset (per HMI Station) to red (priority 1), orange (priority 2), yellow (priority 3), green (priority 4), magenta (priority 5), cyan (priority 6), pink (priority 7), and white (priority 8).
2. Option 2 - When there are any alarms in an alarm group, the associated Control Window Alarm Group button are coloured/flashing as follows: If there are any unacknowledged alarms in any alarm group assigned to the button, the button flashes in the highest priority alarm colour. Otherwise, if there are any unacknowledged return alarms in any alarm group assigned to the button, the button flashes in the return colour. Otherwise, if there are any acknowledged alarms in any alarm group assigned to the button, the button is steady in the highest priority alarm colour. Otherwise, if there are any acknowledged return alarms in any alarm group assigned to the button, the button is steady in the return colour. Otherwise, the button is uncoloured. The button colours are factory preset (per HMI Station) to red (priority 1), orange (priority 2), yellow (priority 3), green (priority 4), magenta (priority 5), cyan (priority 6), pink (priority 7), white (priority 8), and slateblue (return).
3. Option 3 - When there are any unacknowledged alarms in an alarm group, the associated Control Window Alarm Group button is coloured. The button colour is factory preset (per HMI Station) to red.
2.4.4
User and System Windows
The system is configured to support up to 24 working windows/fascias/palettes per console. Each has a thirty-one-character display id, and forty-character description. System displays can be re-configured using the SAMMI Format Editor. This document describes the standard set. For Solaris HMI Stations, the Window Menu button invokes a menu of the following functions, as applicable to the window: a) Window Move. Moves the window. Alternatively, drag the window handle. b) Window Stacking Order Lower. Lowers the window to the bottom of the window stack. Alternatively, use Alt-F3. Also, to cycle through the window stack use Alt-Tab. c) Reset Initial. Resets a previously re-sized window to the initial window display size. d) Window Send to Screen 1/Screen 2. Transfers the window to another screen at this console. e) Window Acknowledge. Acknowledges all points currently in alarm on the window. f) Print (Section 2.14.2). Prints an image of the window on the assigned printer.
Page 28 of 215
2 HMI
g) Window Close. Closes the window. Alternatively, double click on the Window Menu button. For Windows NT/2000 HMI Station, the standard Windows NT/2000 menu button facilitates restore, move, size, minimize, maximize, and close the window. Windows can be re-sized by dragging the window border. If it is reduced to less than the default size, horizontal and/or vertical scroll bars appear. Large displays can be configured with horizontal and/or vertical scroll bars. 2.4.4.1 Window Notes
A window can be configured to have window notes, by including the Notes icon. Window notes allows the user to enter a message online that is then associated with the display on all screens on all HMI Stations throughout the domain. One note per window is supported. The Notes icon appears on the right hand side of the window handle (Solaris HMI Station), or at the configured position within the window (Windows NT/2000 HMI Station). When notes are present, the Notes icon appears in black on yellow, otherwise the icon appears in blue on cyan. The Notes icon invokes a pop-up allowing the note to be viewed and modified. The text is restricted to monochrome ASCII characters. There is no restriction to the total length of text. The notes function is designed for simple text entry, and does not have word processing capability. There is no interlocking between HMI Stations. If two operators modify the same window note, the later modification takes effect. Window notes are synchronized globally during an HMI station restart, and when the notes are modified or deleted. 2.4.4.1.1 Notes in an Alternative Language (e.g. Chinese)
Window notes can be entered in the alternative language (e.g. Chinese) on Solaris HMI Stations, but not on Windows NT/2000 HMI Stations. On Windows NT/2000 HMI Stations, a note in the alternative language can be accessed but the alternative language text is unreadable. It is permissible to add or insert some new English text. However, the alternative language text must not be edited, otherwise it will be unreadable on the Solaris HMI Stations. 2.4.4.2 Date and Time Format
The format of the date and time that is displayed on most user and system windows is configurable. The Command Window, System List Filter Window, User Configured Displays, Point Query Display date/time format is configured using the SAMMI Format Editor. Refer SAMMI Format Editor manual. For the 3-Most Recent Alarms, Alarm List, Event List, Off-Normal List, Administrative Tags List, and Database Server User List, a system startup file defines the date/time format. Formats available include day month year, year month day, and the alternate language format (e.g. the year in Chinese first, then month and day in Chinese). Refer Engineers Manual for available formats. The date/time format is not or partly not configurable for Historical Trend (and Operator Assignable Trend), Historical Tabular (and History Edit), Archive Management Data Display, History Replay Disturbance Selection Menu, History Replay Set Time Range Menu. Except for the Historical Tabular (and History Edit) date/time column that is configurable using the SAMMI Format Editor.
2.4.5
General System Displays
The General System Displays window provides access to system displays. It is possible to restrict function access based on user classes. If a function is not available to a user the button is insensitive and ghosted (note: currently this is not checked for Archive Management functions and History Edit). The Database HMI Station window is shown; on other types of HMI the window is slightly different as described below.
Page 29 of 215
2 HMI
First row (left to right): 1. Station/Network Overview and Statistics (Section 2.13.2). Presents a summary of Solaris stations on the local network from the database's perspective. 2. HMI Data Server/Network Overview (Solaris Databaseless and Windows NT/2000) (Section 2.12.2). Presents a summary of Solaris stations that are able to serve data. 3. Communications Overview (Section 2.13.3.1). Shows the status of FEP stations, communication channels, routes, and RTUs. 4. Communications Statistics (Section 2.13.3.6). Shows statistics on good and error communications for each FEP channel, route and RTU on the system. Next row (left to right): 1. History Utilities (Section 2.9.6). Provides information on history services and storage statistics. 2. Historical Trend (Section 2). Accesses the historical trend displays. 3. Historical Plot (Section 2.9.3). Accesses the historical plot displays. 4. Historical Tabular (Section 2.9.4). Accesses the historical tabular displays. 5. Archive Management (Section 2.10). Accesses the archive management displays that provide management of history file archival/retrieval between disc and DVD RAM. 6. History Replay Mode (Section 2.11). Prompts the operator for a history replay time range and initiates History Replay Console Mode. Next row (left to right): 1. HMI Station Console Assignment (Section 2.12.1). Shows the users that are logged into a Solaris HMI Station. 2. Database Server User List (Section 2.12.3). Shows the HMI Stations that are connected to a database server station. 3. Printer Summary (Solaris HMI Station) (Section 2.14.1). Invokes the Printer Summary Window that displays the status of printers in the system, and allows the user to control printers and assign different functions to them. 4. Reports (Section 2.14.5). Report Generation is used to print a display or series of displays with a customized layout. 5. Report Scheduler (Section 2.14.5.1). The Report Scheduler allows periodic reports to be scheduled. 6. Foreground Log Enable/Disable (Section 2.14.3). This toggle button enables the Foreground Log that supplements the Print Window function with database point information.
2.4.6
Administrative Displays (Tool Box)
The Administrative Displays Window (Tool Box) provides access to administrative displays and other utilities. It is possible to restrict function access based on user classes. If a function is not available to
2 HMI
a user the button is insensitive and ghosted. The Database HMI Station window is shown; on other types of HMI the window is slightly different as described below. First row (left to right): 1. Point Query. Invokes a database Point Information display, the same as described in Section 2.7.1.4, but also allows the user to select the desired database point. 2. Zoom. Allows the viewing scale of a particular window to be changed. This is a standard SAMMI function (Section 2.5.2.1). 3. Display Copy (Section 2.14.2). Prints an image of a selected window. 4. Database List (Section 2.13.1.1). Shows the status of databases, and provides database unload/load. 5. Calculator (Solaris HMI Station). Starts a standard calculator utility. 6. SCADA Program Status (Solaris HMI Station) (Section 2.13.4). For managing iSCADA application programs. 7. Format Editor. On a Solaris HMI Station, this invokes the SAMMI Format Editor, used to create and modify SAMMI displays. The functions of the Format (Display) Editor are described in the SAMMI Format Editor manual. On a Windows NT/2000 HMI Station, this function is invoked via the Windows Start menu.
Page 31 of 215
2 HMI
Next row (left to right): 1. Set Audible Alarm. Allows the user to specify the type, volume and repeat delay of the audible alarm tone. A single sound for all alarm priorities, or a different sound for each alarm priority, can be configured. 2. Alarm Group Button Edit. Allows alarm groups to be assigned to each of the Control Window Alarm Group buttons and to the Alarm List button. 3. FG Printer Admin (Solaris HMI Station). This administration tool displays printer information and current settings. Changes may be made to the settings. 4. Install Formats (Solaris HMI Station). Allows distribution of display format files from the local HMI Station, to any other HMI Station in the domain. 5. Backup (Solaris HMI Station). Creates a tape backup of the operational data (i.e. displays and database (including calculation programs)), both periodically and when changes are made. Next row (left to right): 1. UNIX Logon Admin (Solaris HMI Station). On a Windows NT/2000 HMI Station, NT/2000 Logon Admin is invoked via the Windows Start menu. This provides an administration tool for adding/modifying UNIX/NT/2000 accounts and configuring other system parameters on local station. Refer UNIX/NT/2000 documentation. To add a new UNIX logon account, it is preferred to
2 HMI
use SAMMI (User) Logon Administration tool (see below). 2. SAMMI Logon Admin. An administration tool to add, delete and modify SAMMI user accounts in the HMI system, and add UNIX user (Solaris HMI Station) if required. Refer SAMMI user and administration guide. 3. User Class Admin. A configuration tool that is used to create and modify user classes and to assign users to user class groups. Class permit files can be edited. 4. Distribute User Classes (Solaris HMI Station). Distributes the user class information to all stations in the same domain. 5. Distribute Files (Solaris HMI Station). Distributes a set of files from the local HMI Station to a nominated list of other UNIX stations in the same domain. The main purpose of this is to keep the configuration files the same across the system. A number of pre-configured sets of files are provided, and further sets of files and hosts may be defined and saved. Next row (left to right): 1. XTERM (Solaris HMI Station). Invokes a terminal emulation window for accessing the underlying UNIX system on the local HMI Station. 2. SCADA Server Config (Solaris HMI Station). Allows the servers in a domain to be configured. 3. File Manager (Solaris HMI Station). A UNIX utility that allows the user to manage the file system on the local HMI Station. 4. Text Editor (Solaris HMI Station). General purpose UNIX text editor that can be used for directly editing configuration files on the local HMI Station. 5. Mail Tool (Solaris HMI Station). Allows the current user to view and send electronic mail. Next row (left to right): 1. FG Program Status (Solaris HMI Station). Displays the status of each UNIX HMI task running on the local HMI Station. Tasks may be disabled, restarted, and a task log file displayed. 2. SCADA HMI Option Editor (Windows NT/2000 HMI Station). Invokes the notepad application to edit the NT/2000 HMI options file. 3. SAMMI Security Editor (Windows NT/2000 HMI Station). Invokes the notepad application to edit the SAMMI security file. The security file contains information such as security classes and their privileges. 4. SAMMI Session Manager. For managing SAMMI sessions. Refer SAMMI user and administration guides. 5. SAMMI Process Status. A standard SAMMI display of the status of the logical servers for the current console. Refer SAMMI user and administration guide. 6. SAMMI Logical Servers. A standard SAMMI display of information about the logical servers for the console. This is a standard SAMMI display. Refer SAMMI user and administration guide. 7. Change Password (Solaris HMI Station). Allows the password to be changed on the local station. 8. LOG OFF. Prompts the current user to log off. Next row (left to right): 1. Reload All Tables, Reload Bitmap Symbols, Reload Dynamic Objects, Reload RTDA Tables, and Reload Symbol Tables. Loads offline picture data into the online HMI Station (avoids restarting SAMMI). 2. QUIT SAMMI. Prompts SAMMI to quit. This logs the user off and closes the HMI. Utilities at Default Host (left to right): These functions operate on the current database server station. 1. XTERM at Host. Invokes a terminal emulation window for accessing the underlying UNIX system on the database server station. 2. TELNET to Host (Solaris HMI Station). Invokes a TELNET session window for accessing the underlying UNIX system on the database server station. On a Windows NT/2000 HMI Station, this
2 HMI
function is invoked via the Windows Start menu. 3. DB Config. Starts the Database Configurator at the database server station. Utilities at Remote Host (left to right): These functions allow another database server station to be selected and operated on. 1. Choose The Host. Allows a database server station to be selected from the list of those available. 2. UNIX Logon Admin. Refer description above. 3. SAMMI Logon Admin. Refer description above. 4. User Class Admin. Refer description above. 5. FG Printer Admin. Refer description above. 6. FG Program Status. Refer description above. 7. XTERM at Host. Refer description above. 8. TELNET to Host (Solaris HMI Station). Refer description above. 9. SCADA Program Status. Refer description above.
2.4.7
International HMI Station (Solaris HMI Station)
The HMI Station provides support for dual languages. The primary language is always English. The alternative language is one of the following locales: zh or zh_CN.EUC (Chinese). These locales use the standard GB-2312 character set used in Mainland China. ko or ko_KR.EUC (Korean). These locales use the standard KSC-5601 character set used in Korea.
Alternative language support is provided for the operator's environment only. It is assumed that Operators are poor in the English language, but can understand alphanumeric characters, commonly used in numbers and date/time. The operator's environment includes all text data that an operator would normally read and enter in normal operation of the system. Numbers are unchanged. The HMI Stations functionality in the alternative language is the same as in the primary language (English). When the operator logs on to Solaris, an alternative language for the console can be chosen. To change the language used by the console (i.e. to toggle between primary and alternative languages), the user must log out to UNIX and log back in (this is a limitation of Solaris). The language is on a per console basis, thus it is possible for users to operate under different languages simultaneously on the same HMI station. For the alternative language to function, an alternative set of displays must be prepared. The displays are derived from the standard set of displays and a language dictionary. The alternative set of displays is installed in a pre-defined directory, with display names the same as the displays in the standard set. The alternative displays contain background text data and button labels in the alternative language, with most types of foreground text translated into the alternative language. Details of such configuration can be found in the iSCADA System HMI Engineer's Manual. Text translation is based on a dictionary of phrases. The Engineer, having an intimate knowledge of how the system will be used and the common terminology among operators, configures the dictionary. The accuracy of language translation depends on the dictionary configuration done by the Engineer. The alternative set of displays and language dictionary is not part of the Standard System. Customers requiring them should contact the regional Invensys sales representative. Foreground Text The following types of foreground text are shown in the alternative language. Most types are translated. Point description, point current state, state text, normal state text, point area name, point alarm group name, engineering unit.
Page 34 of 215
2 HMI
Alarm message, alarm state, analogue alarm state. Event message, Event annotation message. Off-normal message. Tag message, tag state. Alarm group filter names list, alarm priority filter names list, area filter names list, category filter names list, event filter type names list, tag filter names list. Display description. Operator confirmation and error messages on fascias.
The following types of foreground text are in English only: Database name, database names list, display ID, domain names, domain names list, history archive info, history services info, history statistics info, point name, point scan device, point type, printer names, printer names list, RTU name, station names, station names list, user name.
Text Entry The only text entered is event annotation, operator tag notes and window notes. On the alternative set of displays, the user may enter text in the alternative language or in English, but the text will be stored as is. There is no text translation. Hence, if the stored text data is in alternative language but the primary display is used to show the data, the result is undefined.
2.5
User Displays
User displays are built using the SAMMI Format Editor. Refer SAMMI Format Editor manual. Variable data is displayed with foreground display components. Some components can be configured with runtime annotation. The variable data can be point current value/status and other point attributes. From analogue, accumulator, and status points, from the online database or historical data. The attributes may be reals, integers, text, or time and date, using any of the appropriate display components.
2.5.1
Runtime Annotation
When point current value/status is displayed, the quality can be presented as runtime annotation. Two character positions next to the data display are reserved for two annotation characters. For example, PT could be used to signify a point is in test mode. Runtime annotation is an option of point display configuration. The quality condition can also apply an overriding colour to the data display. For example, a remote on test condition could force all values (applicable to that remote) to be displayed as white on blue. The annotation characters and overriding colour definitions are stored in a SAMMI configuration file. Quality flags and their propagation to runtime annotation is described in Section 4.3.3. The annotation ER is output for conditions such as a database station failure or a LAN failure. If more than one quality flag is set, the highest priority runtime annotation is displayed. The reason for choosing the order is described below (refer superscript of priority in the table): 1. 2. 3. 4. Control actions are short duration activities that must be brought to the operators attention. Manual override and substitute point overrides all other conditions. Next are telemetry type errors (and their overrides). Suspect, the calculation-propagated manual override/substitute point, must be below telemetry type errors (e.g. so that in a calculation, a propagated manual override/substitute point does not mask telemetry errors). Tags and alarm inhibits must be above alarm condition indications, so that the inhibit action shows. Alarm condition indications. Other inhibits. General Information.
5. 6. 7. 8.
Page 35 of 215
2 HMI
Priority 11 21 32 32 32 43 53 63 73 83 93 103 113 123 133 143 154 16-235 24-315 325 335 345 355 366 376 386 396 406 416 427 437 447 457 468
Point Quality Authorized Change Control Reserved Manual Override Substitute Point Bad Substitute Point RTU Out of Scan Point Out of Scan Scan Error RTU on Test Point on Test Device Forced Data Device Offline Device Comms Lost Input Bad Initial Status Device Restart Suspect Operator Tag 1 to 8 Software Tag 1 to 8 Alarm Inhibit Better Alarm Inhibit Low Alarm Inhibit High Alarm Inhibit Critical High Alarm Critical Low Alarm Exit Critical Alarm High Alarm Low Alarm Exit Alarm Control Inhibit Off-Norm Entry Inh Event Inhibit Zone Event Inhibit Device Chatter
Annotation Fgd Char R A R C C M Y SB C SP Y RS Y PS Y F W RT W PT C DM Y DS Y DF Y B B ? B D? C S M T1-T8 M S1-S8 W I W I W I W I Y CH Y CL Y XC Y H Y L Y X W CI W NI W EI W ZI W DC
Value Colour Fgd Bgd R R C Y C Y Y Y W B W C Y Y Y B B C M M W W W W W M W M Y R W R W R Y W W W W W
Bgd = Background Colour, Fgd = Foreground Colour (i.e. character colour); Y = Yellow; R = Red; B = Blue; W = White; K = Black; M = Magenta; C = Cyan; G = Green; blank = use current colour. Note: there is no runtime annotation for flat line alarm condition.
2.5.2
Display Components
Display components include the following. For a complete set refer to the SAMMI Format Editor Manual. Data Field A data field enables viewing and/or data entry of reals, integers, text, or time and date. Reals, integers and text fields support runtime annotation and flash. Data can be entered directly into a data field, if so configured. The user positions the cursor, types the data, and presses Return. Simple type checking is implemented. Values in multiple fields may be entered, and then stored simultaneously by pressing Return once. Equation Fields Equation fields are like simple data fields, but automatically calculate and display values derived from other data fields in the same window, thereby giving a spreadsheet like capability. The Display Editor is used to build the formulas for calculations into the Equation field. Data entry is not allowed.
Page 36 of 215
2 HMI
Formatted Data Output Fields Formatted Data Output fields are similar to simple data fields except that the data is formatted and/or converted from a predefined table of formatting string and conversion formula pairs. The user determines the formatting and conversions to use. When the field is clicked, the field changes to the next format pair and conversion formula in the table. When the last pair is reached, the next click returns to the first pair. Data entry is not allowed. Dynamic Messages (Text Table) Dynamic messages display text from a table depending on the data value. They support runtime annotation and flash. Dynamic Objects Dynamic objects display one of a set of graphic symbols depending on the data value, e.g. an arrow that appears to rotate and change colour. Each graphic symbol is made up of geometric objects such as lines, circles, boxes or other shapes. A dynamic object can change positions, rotate, flash, change colour, and change line or fill styles. Dynamic Symbols (Symbol Table) Dynamic symbols display one of a set of pictures depending on the data value, e.g. an open or closed valve that changes colour. Each picture is a bit-mapped image. They support runtime annotation to change the colour (but not to append annotation characters). Dynamic symbols have two optional features, borders and labels. The borders have a specified width that gives the image a three-dimensional appearance. Labels can be up to 32 characters long and can be centered below the Dynamic Symbols. Defaults are no borders or labels. Object Icons Object Icons are the same as dynamic symbols, except they are also selectable. When selected they are momentarily highlighted. There are three types: Single select. Sends the command that has been associated with the on condition. Toggle select. Sends a command depending on the on/off condition. Multiple select. Displays a selection list.
Gauges Gauges can be rectangular, round or elliptical. The needle rotates position proportionally to the data value. Features include: Highlighting. The scale from the start to the needle position can be shown in a different colour. Maximum and Minimum Indicators, to reflect the highest and lowest values reached by the data while the display is on the screen. Threshold Indicators, preset by user, or set dynamically by the application. Display of the data value, with runtime annotation support.
Meter Meters are horizontal or vertical rectangles with tick marks and a bar (coloured rectangular area) positioned relative to the scale, proportionally to the data value. They can be fixed-scale linear or moving-scale linear. On the Fixed-Scale Linear Meter, the scale is stationary and the range of values is completely displayed on the scale. The bar indicator moves across the scale as the value changes. Whenever a threshold is passed, the bar colour changes as configured. On the Moving-Scale Linear Meter, the scale moves as the value changes. The bar indicator remains stationary. A narrow band of colour shows the thresholds on the scale. The bar colour does not change. Features include: Maximum and Minimum Indicators, to reflect the highest and lowest values reached by the data while the display is on the screen Threshold Indicators, preset by user, or set dynamically by the application. Display of the data value, with runtime annotation support.
Page 37 of 215
2 HMI
Slider Bars Slider Bars are a graphical representation of slider control switches, they allow data input. They can be horizontal or vertical. The slider moves along a track that represents a range of values. The value can be changed by dragging the slider along the track, or by clicking beside the track at a relative location between the maximum and minimum values. Slider Bars can be configured to always show on the display, or to pop up from a user action (e.g. clicking on a button). Graphs (Plot, Trend) Trends display individual data values over time. Plots display sets of data points. Both may show up to eight curves simultaneously. Features include: A grid consisting of dotted or solid lines in the horizontal and/or vertical direction. Axis tick marks and labels. Re-draw for each new set of data points, or incremental with new data points added to the right. Show the curve as either a continuous line, or a series of unconnected points (scatter plot). Data points on the curve may be marked using symbols, including boxes, triangles, crosses, or Xs.
Clicking on a data point invokes the Dipstick display panel that shows the precise value of the data point. The panel remains on the screen until dismissed. The display of each graph can be controlled by clicking the mouse adjust button in the graph. A control panel appears and provides the following options: Graph Zoom, to change the scale of the x or y-axis. Graph Scroll, to scroll when an axis is zoomed. Autorange Vals. Re-scale both axes so that all available data points fit into the graph area. Restore Vals. Resets the x and y scales back to their original values before zooming. Delay Refresh. Freezes the curve at its current position, so it remains static while viewed. Start Refresh. Unfreezes the curve, so it is re-drawn with the latest data.
Bar Graphs Bar graphs are horizontal or vertical bars sized proportionally to the data values. Features include: The bar changing colour when a threshold has been passed or a configured condition occurs, e.g. pressure at a threshold changes the bar to yellow, then at a higher threshold changes the bar to red. Maximum and Minimum Indicators, to reflect the highest and lowest values reached by the data while the display is on the screen Threshold Indicators, preset by user, or set dynamically by the application. Three-dimensional appearance of the bar. Scale and value type labeling. Display of the data value, with runtime annotation support.
General Action Buttons General Action Buttons can be either: A button that when clicked, initiates a single action (e.g. command), and changes appearance (e.g. looks as if pressed). There is no repeat, no matter how long it is held. A toggle button that on each click, alternates between two states (typically on and off), and changes appearance (e.g. looks as if pressed, and/or the label changes, and/or a miniature indicator inside the button changes look and colour). Toggle buttons can be configured in mutually exclusive groupings. Selecting a toggle button deselects the previously selected button.
A button can be in an insensitive state (i.e. cannot be clicked). The text label appears ghosted. Graphic labels can be configured to change or not change when the button is insensitive. Menus Menus provide a list of selections to activate various functions. Types of Menus are: Menu Panel. A fixed bar with buttons across the top of the window. Pull-down Menu. Can be attached to a menu panel. Clicking on a menu panel button causes the pull-down menu to appear below the menu panel, providing a list of options from which to select.
Page 38 of 215
2 HMI
Cascading Menu. For sub-functions of a pull-down menu. Pop-up Menu. Appears from clicking the mouse menu button anywhere inside the window.
Selection List Selection Lists provide a list choices or actions. They may or may not include a title, Cancel button, OK button, and vertical/horizontal scroll bars. They may permit either single or multiple choices. A Selection List can be configured to always show on the display, or to pop up from a user action (e.g. clicking on an enterable Data field) or for an application requiring the user to make a choice. Text Browser Data Input/Output Field The Text Browser Data Input/Output field is a rectangular window that displays text from a file. It can be static or pop-up. If the line width or text length is greater than the width or length of the Text Browser window, scroll bars appear. A text editor is provided. Note that files containing tabs do not display properly. Optional buttons allow file write, undo (only effective before write), and select another file. 2.5.2.1 Programmable Foreground Display Components
Foreground display components are used to display data, buttons, menus, etc. During offline configuration, the user specifies a key that designates the data to be displayed by a foreground component. The key can either be fixed or programmable. A fixed key means that the data source is absolute. When a window is displayed, the foreground component always shows that data. A programmable key means that the data source can be change online. This feature is available for external applications that wish to change the key definition online. Thus, depending on circumstances, the application may decide what data is to be fetched for display at any time. For the key to be programmable, it must be configured to use an application symbol. Then the application symbol simply sends a command to change the application symbol's value. Details on the symbol configuration and commands can be found in the iSCADA System HMI Engineer's Manual. 2.5.2.2 Foreground Display DDO Key Concatenation
Foreground display component key concatenation allows multiple text segments to be joined into a new word and a range of characters within the new word extracted to form the final key. For example, one display could be used for many similar stations. For this, the point name references would be text strings containing say a station name, where the station name is substituted. Further details can be found in the iSCADA System HMI Engineer's Manual - Concatenation Operator.
2.5.3
2.5.3.1
Zoom and De-Clutter

Zoom Function
Zooming is used to magnify information displayed in windows. A Zoom window application allows the user to zoom to pre-defined levels of magnification. The manner in which information is displayed when varies between windows: Windows configured for de-clutter, allow zooming between different layers of information. Windows not configured for de-clutter, just make the window bigger or smaller, depending on the magnification.
For example, a window with a picture of a multi-product pipeline stretching several hundred kilometres may overlay information concerning the general health of the source stations and the status of various areas. By zooming in, detailed information on one station of the pipeline may be viewed. For instance, from this layer several valves that have closed in the line-of-flow, the batch number affected, the density of the product currently in the pipeline, and its desired time of arrival at the destination station, are visualised. Perhaps by zooming out just a little, an overview of that station is shown indicating that it had entered an emergency shutdown procedure. De-cluttering gives an easy way of traversing several layers of detail and provides a logical way to navigate through process information.
Page 39 of 215
2 HMI
Further information regarding zooming may be obtained from the Sammi Format Editor Guide. 2.5.3.2 Zoom Options
The following zoom options are available: Full View Zoom In Zoom Out Zoom Box Return the format to its normal size. Magnifies the displayed information. De-magnifies the displayed information. Allows the user to use an expandable/contractible box outline to select an area to zoom on, in the current display. Once the box is drawn, the area inside of it is scaled and panned so that the contents of the box fill the application area.
2.5.3.3
Features of the Zoom Window
The following zoom buttons (factors) are available: 2:1 4:1 8:1 1:2 1:4 1:8 Full Magnify the outlined area of the format by a factor of 2. Magnify the outlined area of the format by a factor of 4. Magnify the outlined area of the format by a factor of 8. De-magnify the outlined area of the format by a factor of 2. De-magnify the outlined area of the format by a factor of 4. De-magnify the outlined area of the format by a factor of 8. Return the format to its normal size (i.e. 1:1).
2.6
System Lists
The iSCADA System maintains four types of chronologically sorted system lists, displayed and managed for the operators areas of responsibility. The operators areas of responsibility are determined from the current user class. The system list types are: Alarms List - a list of alarms. Events List - a list of events. Off-Normals List - a list of off-normal conditions. Administrative Tags List - a list of points that have administrative flags attached.
The standard HMI station configuration contains one window of each system list type. Any number of system list windows for each type can be configured. The system lists are invoked from buttons on the Command Window (refer Section 2.4.1). The system lists can be filtered to show entries of interest (refer Section 2.6.5).
2.6.1
Alarm List
Alarm generation and management is described in Section 5. The Alarm list is a chronologically sorted list of alarms for the operators areas of responsibility. An alarm entry is added to the Alarms List on annunciation of an alarm condition. New entries flash for easy identification. Selecting the entry in the Alarms List and clicking the Acknowledge button acknowledges the alarm. The entry ceases to flash. For digital points, there is one alarm entry for a point. For analogue points, there can be two alarm entries for a point, one for the zone alarm and the other for the flat line alarm. Subsequent annunciation flashes and updates the same alarm entry to reflect the new alarm condition (i.e. a new entry is not added to the Alarms List). Alarms that are bad due to cause-alarm (e.g. conversion error, over/under range) are shown. Other bad conditions are not shown, unless an entry for that condition existed before it went bad. An alarm entry can be deleted from the Alarms List, provided that it has been acknowledged. Thus, at any point in time, the Alarms List may or may not contain a complete record of all alarms that have occurred over a specific period of time. After an alarm has been deleted, the list is automatically compacted.
Page 40 of 215
2 HMI
The standard list displays 20 entries, up to 40 can be configured. Each entry is time tagged to a resolution of seconds. The list is updated every second. The list does not display alarms from currently non-operational stations.
Al_R5_filt_alarms: Filtered Alarms
24 24 24 25 24 24 24 24 24 24 24 24 24 25 24 24 24 24 24 24 24 24 May May May May May May May May May May May May May May May May May May May May May May 02:10:32 03:19:37 03:19:37 16:55:42 03:19:38 03:19:39 03:19:39 23:14:40 14:11:54 03:19:41 23:51:24 13:19:37 19:09:46 02:34:17 18:09:46 17:44:33 17:44:34 17:44:34 23:19:39 17:44:35 17:44:35 17:44:36 11KV TRANSFORMER A CURRENT ISOLATOR FDR 245 RTU #5 11KV TRANSFORMER B CURRENT ISOLATOR FDR 246 33KV NO 6 CCT BREAKER GEN A SEAL OIL INLET 11KV TRANSFORMER A TEMP 11KV TRANSFORMER B TEMP GEN D SEAL OIL INLET FAN B HOUSING FIRE COMMS LINE #3 GEN C SEAL OIL INLET 11KV TRANSFORMER D CURRENT COMMS LINE #4 FAN A HOUSING FIRE 11KV NO 1 CCT BREAKER 11KV NO 2 CCT BREAKER 11KV TRANSFORMER D TEMP 11KV TRANSFORMER D TEMP ISOLATOR FDR 303 GEN B SEAL OIL INLET HIGH ALARM OPEN FAILED HIGH ALARM OPEN INVALID LOW ALARM HIGH ALARM HIGH EXIT CRIT LOW EXIT OUT FAILED LOW EXIT CRITICAL HIGH RECOVERED OPEN OPEN OPEN CRIT HIGH EXIT OVER RANGE CONV ERROR CRITICAL LOW 280.0 AMPS ALM 1 ALM ALM BAD ALM ALM ALM 1 WRS 6 RTN BTR 12 RTN ALM RTN WRS 25 RTN ALM BAD ALM BTR 17 BAD BAD ALM 5 Top
277.4 AMPS
Filter Acknowledge
31.9 116.0 78.3 18.9
KPA DEGC DEGC KPA
Delete Page Mode Line Mode
42.6 KPA 336.7 AMPS
240.2 DEGC 240.2 DEGC 15.1 KPA
Bottom
Any combination of the following is configurable, in a system startup file, on a per HMI station basis: To display either the top page or bottom page when invoked. Top page is the default. To be in the Page Mode or Line Mode when invoked. Page Mode is the default.
Any combination of the following filter/sort options is selectable, via the Filter Fascia (Section 2.6.5), on a per HMI station basis: Alarm condition - display all alarms, or only unacknowledged alarms, or only acknowledged alarms. Sort on first annunciation time, or last annunciation time. For sort on first annunciation time, the alarm entry does not move in the list if the time is updated, thus alarms could appear to be out of order. For sort on last annunciation time, the alarm entry moves if the time is updated. The alarms are always in time order. The oldest alarm at the top, or the newest alarm at the top. For the oldest alarm at the top, new alarms are added to the bottom. When the page is full, they are put on the next page. For the newest alarm at the top, new alarms are inserted at the top pushing all alarms down the page. If the page is full, alarms are pushed onto the next page. Sort on alarm priority order, or ignore alarm priority. For sort on alarm priority order, the highest priority alarms appear on top of lower priority alarms. The oldest/newest on top selection works within each alarm priority. For ignore alarm priority, the oldest/newest on top selection works on the list as a whole. The illustrated alarm list has display of all alarms, sort on first annunciation time, oldest alarm at the top of the list, and ignores alarm priority in the sort order. 2.6.1.1 Alarm Entry
An alarm entry consists of the following fields: 1) Last annunciation time Date and time when the alarm state last changed. The date flashes for all unacknowledged alarms. The date and time colour is dependent on the alarm state. It is configurable on a per HMI station basis, the default is: Alarm State ALM WRS BTR
Date and Time Field Colour Black on Red Black on Magenta Magenta on Black
Page 41 of 215
2 HMI
RTN BAD 2) Description
Red on Black Black on Blue
Point description (40 bytes maximum). The colour of the description and remainder of the line is dependent on the alarm priority. It is configurable on a per HMI station basis, the default is: Alarm Priority Alarm Description Field Colour 1 Red on Black 2 Orange on Black 3 Yellow on Black 4 Green on Black 5 Magenta on Black 6 Cyan on Black 7 Pink on Black 8 White on Black (Digital) Current state of the point. Or cause-alarm point quality text. (Analogue Zone) Current alarm state in terms of alarm limits. Possible states are CRITICAL HIGH, CRITICAL LOW, CRIT HIGH EXIT, CRIT LOW EXIT, HIGH ALARM, LOW ALARM, HIGH EXIT, LOW EXIT, and NORMAL. Or cause-alarm point quality text (e.g. OVER RANGE, UNDER RANGE). (Analogue Flat Line) Current alarm state in terms of flat line condition. Possible states are Flat, FlatExit, FlatConversionError, FlatOverRange, FlatUnderRange. (Analogue Zone) Current value of the point. (Analogue Flat Line) Current value of the point. Only updated when annunciated (entry and exit). (Analogue) Engineering units for the point. Current alarm state. Possible states are: ALM (Alarm). (Analogue) The point first goes into alarm. (Digital) The point is in an alarm state. WRS (Worse). (Analogue) The point value moves to a higher zone. BTR (Better). (Analogue) The point value moves to a lower zone. RTN (Return to non-alarm). (Analogue) The point returns to non-alarm. (Digital) The point is in the non-alarm state. BAD (Bad Data). (Analogue and digital) The point changes to bad data quality (includes both cause-alarm and suspend-alarm). Refer Section 4.3.2.
3a) Current state 3b) Alarm state (limits)
3c) Alarm state (flat line)
4a) Current value 4b) Current value 5) 6) Engineering units Alarm state
7)
Current Zone
(Analogue Zone) The current alarm zone. Zero if in normal zone.
2.6.1.2
Function Buttons
Alarm List function buttons are as follows: Top. Move to the top of the Alarm List. Filter. Invoke the Filter Fascia, which allows the Alarm List to be filtered (refer Section 2.6.5). Acknowledge. Acknowledge alarm conditions (refer Section 5.5). Delete. Delete alarms (refer Section 5.7).
2 HMI
Page Mode. Change the Alarm List display to Page Mode. In Page Mode, the Acknowledge and Delete buttons operate on all alarm entries displayed on the current page. Selecting an alarm entry invokes the Point Palette. Line Mode. Change the Alarm List display to Line Mode. In Line Mode, the Acknowledge and Delete buttons operate on all alarm entries that are currently selected. Clicking on an alarm entry causes selection (with highlighting), clicking again causes de-selection. Bottom. Move to the bottom of the Alarm List.
2.6.2
Event List
The Event list is a chronologically sorted list of events for the operators areas of responsibility. An event is any incident in the system that is stored as a permanent record. Events include alarms, status changes, operator actions, and system generated events such as communication errors. An entry is added to the Events List on occurrence of an event condition. Each event condition generates a new entry. Annotations may be attached to an event entry, e.g. to record a particular circumstance surrounding the event. Event entries cannot be manually deleted. The standard list displays 20 entries, up to 40 can be configured. Each event is time tagged to a resolution of seconds, with some event types to a resolution of milliseconds. When the page containing the newest events is displayed, it is refreshed with the newly added events. When other pages are displayed, they are not updated. The list includes events that have already been collected from stations that are currently non-operational.
Al_R5_filt_events: Filtered Events
26 26 26 26 26 26 26 26 26 26 26 26 26 May May May May May May May May May May May May May 01 01 01 01 01 01 01 01 01 01 01 01 01 02:10:32 03:19:37.550 03:19:37 03:19:38 03:19:38 03:19:39 03:19:39.983 04:14:40 04:19:38 33KV LINE C VOLTAGE HIGH ALARM 34.2 KV ALM 1 ISOLATOR FDR 245 OPEN RTU #5 FAILED 11KV TRANSFORMER B CURRENT CRITICAL HIGH 297.4 AMPS WRS 12 COMMS LINE #3 FAILED GEN A SEAL OIL INLET LOW EXIT 31.9 KPA RTN ISOLATOR FDR 247 BAD NO 3 CONDENSER TEMP HIGH ALARM 55.0 DEGC ALM 1 11KV TRANSFORMER B CURRENT CRITICAL HIGH 306.7 AMPS WRS 13 <This is an example of annotation that has been inserted > 05:01:22 11KV TRANSFORMER B CURRENT CRIT HIGH EXIT 305.2 AMPS BTR 13 05:44:35.256 ISOLATOR FDR 303 CLOSE 05:44:36 GEN B SEAL OIL INLET LOW ALARM 29.5 KPA ALM 1 07:51:54 engineer on vv1:0->vv1 GEN A SEAL OIL INLET Manual Override On 08:11:37 engineer on vv1:0->vv1 GEN A SEAL OIL INLET value changed to 50.0 08:11:38 GEN A SEAL OIL INLET HIGH EXIT 50.0 KPA RTN 08:43:35 11KV TRANSFORMER B CURRENT CRIT HIGH EXIT 299.8 AMPS BTR 12 09:16:38 11KV TRANSFORMER B CURRENT HIGH ALARM 290.5 AMPS BTR 11 10:51:24 FAN B HOUSING FIRE OUT 13:19:37 11KV TRANSFORMER B CURRENT Over Range 2043 Top Filter View Mode Annotate Mode Archived Files Oldest File
26 May 01 26 26 26 26 26 May May May May May 01 01 01 01 01
Current File Bottom
The Event List shows the latest event (in the current online event file) when invoked. It can be configured to be in the View Mode or Annotate Mode when invoked. View Mode is the default. A system startup file per HMI station defines this configuration. The following event orders are configurable per HMI station. a) With the newest event at the top of the list. New events are inserted at the top of the first event page, pushing all events down the page. b) With the newest event at the bottom of the list (as illustrated). New events are inserted at the bottom of the last event page, pushing all events up the page. If there is a time change (e.g. daylight saving), the event times show a forward or back jump. The Event List consists of a number of online event files (e.g. 8 daily files, each consisting of up to 100,000 event records (lines)), with older events accessible from archived files on DVD RAM (refer Section 6.7).
Page 43 of 215
2 HMI
2.6.2.1
Event Entry
Types of event entries are: a) Alarms and other point status changes, coloured white on black. The format is similar to the entry on the Alarm List. Time is displayed with millisecond resolution for time tagged digitals that are configured with an update time resolution of milliseconds. For an analogue point that goes over/under range, the event also shows the input value, except when it was caused by removing manual override or point substitution. For telemetered points the ADC value is shown. For calculated points the engineering value is shown. b) Operator actions, coloured green on black. A typical entry consists of the date/time, user ID & station performed on, point description and action. Some entries (e.g. for alarm acknowledge, alarm delete) only have the date/time, point description and action. c) Communication errors, coloured cyan on black. A typical entry consists of the date/time, RTU name and error description (e.g. communications lost to RTU). d) Fail messages, coloured red on black. A typical entry consists of the date/time, point description and error description (e.g. fail-to-operate). e) System messages, coloured yellow on black. A typical entry consists of the date/time, station name and description (e.g. database started). f) Event annotation, colour chosen by user. The entry consists of the user-entered text enclosed in angle brackets (e.g. <Level transducer possibly faulty, check with maintenance group >).
g) Tag notes. When an operator tag is applied with a tag note, the tag note is put in the Event List following the associated event message. The tag note is on a separate line, similar to event annotation but different colour. It has no date/time. The tag note shows with the event for any list filtering. When the operator tag is removed, the associated event message does not show a tag note. 2.6.2.2 Viewing Online Events - Online Event Files as Separate Files
Normally the Event List display treats the online event files as separate files (default mode). A system startup file defines which mode the Event List is in when it is invoked. Events are selected from the online event files as follows: Top. Move to the top of the currently selected event file. Bottom. Move to the bottom of the currently selected event file. Scroll Bar. Scroll within the currently selected event file. Oldest File. Access the oldest online event file. Current File. Access the current online event file. <, >. Scroll between online event files. 2.6.2.3 Viewing Online Events - Online Event Files as Continuous List
Alternatively, the Event List display can be selected to treat the online event files as one continuous list. In continuous list mode the system memory usage and CPU load may be impacted depending on the total number of online event file records. Events are selected from the online event files as follows: 0. Select continuous list mode. Top. Move to the top of the online events. Bottom. Move to the bottom of the online events Scroll Bar. Scroll within the online events.
2 HMI
Oldest File. Not used. Current File. Exit the continuous list mode. <, >. Not used. 2.6.2.4 Viewing Archived Events
The files on the currently mounted DVD RAM disc are available for viewing. Refer Section 2.10 for information on DVD RAM management. Archived Files. Click Archived Files to invoke a popup list of all archive files available for selection, then click on the desired file name, and then click OK. Note that the archive event file name does not indicate the physical location of the file. The popup list lists the files showing only the time periods covered by each file. The list consists of: Files on the currently mounted DVD RAM disc. These files are accessed directly from DVD RAM, and consequently have a slower access than those on disc. Files ready for archive to DVD RAM. Files that have been archived to DVD RAM (and not yet deleted from disc).
Top. Move to the top of the currently selected event file. Bottom. Move to the bottom of the currently selected event file. Scroll Bar. Scroll within the currently selected event file. 2.6.2.5 Other Function Buttons
Other Event List function buttons are as follows: Filter. Invoke the Filter Fascia, which allows the Event List to be filtered (refer Section 2.6.5). View Mode. Change the Event List display to View Mode. In View Mode, selecting an entry for a point event invokes the point palette. Selecting non-point related entries (e.g. system event message, operator action message, annotation, etc) have no effect. Annotate Mode. Change the Event List display to Annotate Mode. In Annotate Mode, selecting an entry in the Event List, invokes the Annotation Selection Palette (refer Section 2.6.2.6). 2.6.2.6 Event Annotation
Annotation lines can be appended to an event, and are propagated to all stations maintaining an event file. Annotations appear with the event when events are filtered. There is no limit on the number of lines per entry. However, each line is restricted to 66 characters. All annotations appear on a black background. The foreground colour of each annotation may be selected to be, white, yellow, magenta, red, cyan, green, blue, black. The annotation colour can be different to the colour event. Selecting the event entry allows an annotation line to be added to the event. Selecting an existing annotation entry allows the annotation to be deleted, modified, or another annotation line to be added. All annotation actions generate an operator action event. Only events in the current and previous online event file can be annotated. If at the time of annotation action completion, the entry is no longer in the current and previous online event file, the changes are discarded.
2.6.3
Off-Normal List
Analogue points that are outside their normal operating range are flagged as being off-normal. A
Page 45 of 215
2 HMI
digital point is flagged as being off-normal if it is not in its configured normal state. For example, the digital point that represents an electrical circuit breaker might be defined to be off-normal when the circuit breaker is open. Digital points that do not have a normal state defined are always considered to be in their normal state. The Off-Normal List is a chronologically sorted list of points that are not in their normal state, for the operators areas of responsibility. For digital points, there can be one entry for a point. For analogue points, there can be two entries for a point, one for the zone condition and the other for the flat line condition. The Off-Normal List contains: Analogue points that are outside their normal operating range (i.e. in high or low alarm), or in the flat line condition. Digital points that are not in their normal state. Points that are bad due to cause-alarm (e.g. conversion error, over/under range). Note: the list does not display points that are bad due to other conditions.
Entries cannot be manually deleted. The standard list displays 20 entries, up to 40 can be configured. Each entry is time tagged to a resolution of seconds. The list does not display alarms from currently non-operational stations. For further information on off-normals refer to Section 6.7.
offnormals:
22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 May May May May May May May May May May May May May May May May May May May May May May 02:10:32 03:19:37 03:19:37 03:19:38 03:19:38 03:19:39 03:19:39 04:14:40 04:19:38 04:23:59 05:01:22 05:44:35 05:44:35 05:44:36 07:51:54 07:51:59 08:11:37 08:11:37 08:11:38 08:43:35 09:16:38 10:51:24 33KV LINE C VOLTAGE ISOLATOR FDR 245 FD X234 FAN BEARING TEMP 11KV TRANSFORMER B CURRENT COOLING TOWER #3 EPA GEN A SEAL OIL INLET ISOLATOR FDR 247 NO 3 CONDENSER TEMP COOLING TOWER #2 EPA COOLING TOWER #1 EPA 11KV BUS 2 CIRCUIT BREAKER 11KV BUS 3 CIRCUIT BREAKER ISOLATOR FDR 303 GEN B SEAL OIL INLET ISOLATOR FDR 304 ISOLATOR FDR 305 FAN B HOUSING FIRE FIRE ENGINE WATER SUPPLY PUMP INSURANCE POLICY THINGS ARE IN HIGH ALARM OPEN HIGH ALARM CRIT HIGH OUT OF SERVICE LOW ALARM OPEN LOW ALARM OUT OF SERVICE OUT OF SERVICE OPEN IN TRANSIT OPEN LOW EXIT INVALID OPEN ON FIRE OUT OF SERVICE LOW BROKEN EXPIRED A STATE 36.9 KV Filter 98.3 DEGC 295.4 AMPS 31.9 KPA 12.3 DEGC
42.6 KPA
The Off-Normal List is sorted with the newest entry at the bottom of the list. When the page is full, new entries are put on the next page. 2.6.3.1 Off-Normal Entry
The format of the Off-Normal entry is the same as for the Alarm List (except there is no alarm state/zone). It is coloured white on black. The time is when the abnormal condition was detected (e.g. first annunciation time). 2.6.3.2 Function Buttons
Off-Normal List function buttons are as follows: Filter. Invoke the Filter Fascia, which allows the Off-Normal List to be filtered (refer Section 2.6.5).
2.6.4
Administrative Tags List
The Administrative Tags list is a chronologically sorted list of points that have administrative flags attached, for the operators areas of responsibility. A given point has a separate entry for each tag that is currently set.
2 HMI
The Administrative Tags List contains all administrative flags except RTU on test and RTU out of scan. Administrative tags are point quality flags, typically set/cleared by operator functions (e.g. Point On Test, Manual Override, Alarm Inhibit, Operator Tags, etc). Some administrative flags are only applicable to some point types (e.g. Better Alarm Inhibit is only applicable to analogue points). For further information on administrative tags refer to Section 4.3.1. Entries cannot be manually deleted. The standard list displays 20 entries, up to 40 can be configured. Each entry is time tagged to a resolution of seconds. The list does not display alarms from currently non-operational stations.
tags:
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 May May May May May May May May May May May May May May May May May May May May May May 02:10:32 03:19:37 03:19:37 03:19:38 03:19:38 03:19:39 03:19:39 04:14:40 04:19:38 04:23:59 05:01:22 05:44:35 05:44:35 05:44:36 07:51:54 07:51:59 08:11:37 08:11:37 08:11:38 08:43:35 09:16:38 10:51:24 33KV LINE C VOLTAGE ISOLATOR FDR 245 FD X234 FAN BEARING TEMP 11KV TRANSFORMER B CURRENT COOLING TOWER #3 EPA GEN A SEAL OIL INLET ISOLATOR FDR 247 GEN A SEAL OIL INLET GEN A SEAL OIL INLET GEN A SEAL OIL INLET 11KV BUS 2 CIRCUIT BREAKER 11KV BUS 3 CIRCUIT BREAKER ISOLATOR FDR 303 GEN B SEAL OIL INLET ISOLATOR FDR 304 ISOLATOR FDR 305 11KV BUS 2 CIRCUIT BREAKER 11KV BUS 2 CIRCUIT BREAKER 11KV BUS 2 CIRCUIT BREAKER ISOLATOR FDR 305 ISOLATOR FDR 305 ISOLATOR FDR 305 ALARMS INHIBITED OPERATOR TAG 8 HIGH ALARM DISABLED LO ALARM DISABLED MANUAL OVERRIDE EXIT LIMIT ALARM INHIBITED MANUAL OVERRIDE OPERATOR TAG 1 OPERATOR TAG 2 OPERATOR TAG 3 POINT ON TEST MANUAL OVERRIDE POINT ON TEST POINT OUT OF SCAN OPERATOR TAG 1 MANUAL OVERRIDE LO ALARM DISABLED BETTER ALARM INHIBIT ZONE EVENT INHIBIT OFF NORMAL DISABLED EVENT INHIBIT CONTROL INHIBIT Filter
The Administrative Tags List is sorted with the newest entry at the bottom of the list. When the page is full, new entries are put on the next page. 2.6.4.1 Administrative Tags Entry
The format of all point types in the Administrative Tags entry is the same as for a digital point in the Alarm List (except there is no alarm state). It is coloured green on black. When an operator tag is ON and it has a tag note, the tag note is shown in the Administrative Tags list following the associated tag entry. The tag note is on a separate line, similar to the Event List. It has no date/time. The tag note shows with the tag entry for any list filtering. 2.6.4.2 Function Buttons
Off-Normal List function buttons are as follows: Filter. Invoke the Filter Fascia, which allows the Administrative Tags List to be filtered (refer Section 2.6.5).
2.6.5
System List Filtering and Sort Options
Each system list has a Filter button that allows the user to filter the system list to show only those entries of interest. The Filter button is coloured red if any filtering is active. For the Alarm List, the Filter Fascia also allows the Alarm List sort options to be selected. Filter Parameters Any combination of the filtering parameters shown in the table for the given list type can be selected. Filter Criteria Area1 Alarm Group Alarm List ! ! Event List ! ! Off-Normal List ! ! Administrative Tags List ! !
Page 47 of 215
2 HMI
Category2 Time Alarm Priority Alarm Condition3 Event Type4 Point Quality Flags Notes:
! ! ! !
! !
! !
! !
! !
1. Only system list entries in the operators areas of responsibility are displayed, regardless of Set ALL areas or individual area selections (i.e. selecting an area outside the operators areas of responsibility does not cause system list entries from that area to be displayed). 2. List entries for points that are not assigned a category, are displayed by Set ALL categories. 3. Alarm Condition means Acknowledged or Unacknowledged. The filter allows either one or both to be selected. 4. Event type is, for example, a system message, communications error, manual entry, control, failto-operate, alarm acknowledge, etc. Sort Options Any combination of the sort options shown in the table for the given list type can be selected. Display Option Time Selection1 Sort Order Oldest/Newest1 Sort Order Priority1 1. Refer Section 2.6.1. Alarm List ! ! ! Event List Off-Normal List Administrative Tags List
2.7
2.7.1
Point Administrative Functions

Point Palette
Selecting a point or list entry on a window pops up a palette containing the functions available for that point. The point palette is similar for the various point types. Selecting a function from the palette, either executes the function directly, or invokes a point fascia. The palette then closes. Functions, other than those that simply display information, are only permitted if the point belongs to the operators areas of responsibility. The operators areas of responsibility are determined from the current user class. The following functions are provided: Invoke the Supervisory Control Fascia. Acknowledge the points alarm condition. Initiate a demand scan. Invoke the Operator Tags Fascia. Invoke the Point Attributes Fascia. Assign point to an Operator Assignable Trend Display. Invoke the Point Information Display. Invoke the Analogue Limits Fascia. Quick display call-up from point value/alarm entry. Reset the accumulator value (calculated accumulator points).
Optionally, the palette can be configured not to allow controls or tag functions when the palette is
Page 48 of 215
2 HMI
invoked from the Alarms, Events, Off-Normals, Administrative Tags or 3-Most Recent Alarms Windows. The option is factory preset in a system startup file to allow controls and tag functions. A typical point palette is as follows:
2.7.1.1
Function Buttons
Point Palette function buttons are as follows: Control... Invoke the Supervisory Control Fascia, for supervisory control (refer Section 2.8). Acknowledge. Acknowledge the points alarm condition (refer Section 5.5.1). Scan. Initiate a demand scan, to update the point value from the field (refer Section 2.7.1.2). Tags... Invoke the Operator Tags Fascia, which allows operator tags to be applied/removed (refer Section 2.7.1.3). Attributes... Invoke the Point Attributes Fascia, which allows attributes to be enabled/disabled (refer Section 2.7.2). Limits... Invoke the Analogue Limits Fascia, which allows limits to be viewed/altered (refer Section 2.7.2.7). Assign Trend. Assign point to an Operator Assignable Trend Display (refer Section 2.9.2). Detail. Invoke the Point Information Display, which displays the points static and dynamic attributes (refer Section 2.7.1.4). Display. Quick display call-up provides access to display(s) that the point appears on (refer Section 2.7.1.5). Reset. Reset the accumulator value (refer Section 2.7.1.5). 2.7.1.2 Demand Scan a point
The operator can request a telemetered points value and quality be updated with the current field data, by initiating a demand scan of the point. Depending on the communications protocol, this may scan just this point, or may have to scan a number of points, or the whole RTU. An operator action event is not generated.
Page 49 of 215
2 HMI
2.7.1.3
Operator Tags and Tag Notes
Eight operator tags are provided to indicate specific user-definable conditions of points and/or the equipment they relate to. For example, one operator tag can be used to indicate that the equipment is electrically isolated, and another to indicate that the equipment has been removed for maintenance. The Point (Operator) Tags fascia contains a toggle button for each of the 8 operator tags. If a given tag is not configured for the point, the button is blank. The button label indicates if the given tag is currently applied or not. The operator can enter a tag note when applying an operator tag. Tag Notes are added, removed and viewed via the Point Tags fascia. The tag note is shown on the Event and Administrative Tags List Displays with the tag entry. Tag notes are synchronized between stations. There is no loss of tag notes on software upgrade or database migration. The Point Tags fascia has a 78-character tag notes field for each of the eight operator tags. If the tag is currently ON, the field shows the tag note that was entered by the user when the tag was set. If no note was entered then the field is blank. If the tag is currently OFF, the tag notes field shows blank. Each point can have up to eight tag notes applied concurrently. It is the users responsibility to be aware of the affect on performance of having large numbers of tag notes stored in the system (refer Section 14). 2.7.1.4 Point Information
The Point Information display contains all the configuration and dynamic information for the point. This includes the parameters from the Database Configurator point forms (e.g. minimum and maximum engineering values, area, alarm group, time delays, attribute, etc), and the current value/state, individual quality flags, etc. An operator action event is not generated when the display is invoked. There are two ways of invoking the Point Information display: Method 1 Method 2 From the Point Palette, click the Detail button. From the Administrative Displays Window, click the Point Query button and enter the desired point name. Display (Solaris HMI Station)
2.7.1.5
A point may be configured on one or more displays. The Display function allows the user to jump to these displays. If there are no associated displays, the button is insensitive. If the point is on one display only, then that display is invoked. If the point is on more than one display, the list of displays is invoked. The function uses an internal list of points and displays. This list must be re-built using an offline utility, whenever points are added to or deleted from displays (Refer to iSCADA System HMI Engineers Manual for further details). Note that only points with hard-coded names are detected by the offline utility. For example, point names constructed using DDO key concatenation are not detected by the offline utility, and therefore that display does not appear in the list of displays for the point. 2.7.1.6 Accumulator Reset
A calculated accumulator point can be manually reset. For a current value type of calculated accumulator point, the current value contains the current accumulated value (in engineering units) over a time period. The accumulation period is configurable as a specific period or can be continuously accumulating. The Reset function clears the points current value and quality flags. For a completed value type of calculated accumulator point, the current value retains the previous period accumulation value, for the whole of the current period. Accumulation for the current period is internal to the point. The accumulation period is configurable as a specific period (it cannot be continuously accumulating). The Reset function clears the internal accumulated value and quality flags, as well as the points current value and quality flags. An operator action event is generated.
Page 50 of 215
2 HMI
2.7.2

Point Attributes
The following point attribute functions are available from the Point Attributes Fascia: Alarm Inhibit/Enable. Event Inhibit/Enable. Off-Normal Inhibit/Enable. Enable/Disable Scanning. Put Point On/Off Test. Change Normal State (digital points). Apply/Remove Manual Override. Enter Manual Value (or State). Apply/Remove Substitute Point.
If an attribute is not applicable to the point, the button is blank. Several functions can be performed. The database is not affected until the Enter button is pressed. Operator action events are generated for attributes that have changed. If a function is not successful, an appropriate error message appears. A typical point attributes fascia is as follows:
2.7.2.1
Function Buttons and Fields
Point Attributes fascia function buttons and fields are as follows: Inhibit/Enable Alarm. Inhibit/enable the points alarm generation (refer Section 5.8.1). Inhibit/Enable Event. Inhibit/enable the points event generation (refer Section 6.6.1). Inhibit/Enable Off-Normal. Inhibit/enable the points off-normal generation (refer Section 7.6.1). Enable/Disable Scanning. Enable/disable scan input processing (refer Section 2.7.2.2). Place On/Off Test. Put point into/out of test mode (refer Section 2.7.2.3). Normal field. Change the currently defined points normal state (refer Section 2.7.2.4). Apply/Remove Manual Override. Put point into/out of manual override (refer Section 2.7.2.5). Current Value/State field. Displays the points current value/state, and allows a manual value (or
2 HMI
state) to be entered (refer Section 2.7.2.6). Apply/Remove Substitute Point. Turn on/off point substitution (refer Section 2.7.2.7). Source Point ID field. Displays the source point name for point substitution, and allows it to be changed (refer Section 2.7.2.6). 2.7.2.2 Enable/Disable Scanning
The scan input processing of a telemetered point can be disabled (e.g. when the field value is invalid). The input is still scanned into the master station but the point is not processed or updated from that input. When scanning is disabled (i.e. take point out of scan): The point is flagged point out of scan. The associated input is still scanned but point processing stops. An entry is made in the Administrative Tags List. An operator action event is generated.
When scanning is enabled (i.e. put point into scan): The point out of scan flag is cleared from the point. The point is demand scanned. The related Administrative Tags List entry is deleted. An operator action event is generated. Put Point On/Off Test
2.7.2.3
A telemetered or manual point can be put into test mode (point on test) (e.g. when a field transducer is being tested). The input is processed in the normal manner. Alarm, event, off-normal processing and controls are inhibited as configured in Common Data - Inhibit Masks. When the point is put on test: The point is flagged point on test. An entry is made in the Administrative Tags List. An operator action event is generated.
When the point is taken off test: The point on test flag is cleared from the point. The related Administrative Tags List entry is deleted. An operator action event is generated. Change Normal State (Digital Points)
2.7.2.4
The currently defined normal state (i.e. the normal state definition) for the point is shown in the Normal field, and can be changed by clicking on the field. The normal state can be either A-state or B-state. 2.7.2.5 Apply/Remove Manual Override
A telemetered or calculated point can be manually overridden. When the point is in manual override, its value is not affected by point substitution, or by changes in the field or calculations, until manual override is removed. A new value can be manually entered (refer Section 2.7.2.6). When manual override is applied: The point is flagged manual override. The associated input is still scanned to update the bad data quality flags. An entry is made in the Administrative Tags List. An operator action event is generated.
When manual override is removed:
Page 52 of 215
2 HMI
The manual override flag is cleared from the point. The point is updated from a substituted point or demand scanned, as appropriate. The related Administrative Tags List entry is deleted. An operator action event is generated. Enter Manual Value (or State)
2.7.2.6
A point value can be manually changed. The manual change automatically sets a telemetered or calculated point into manual override. 2.7.2.7 Apply/Remove Substitute Point
A telemetered point can have point substitution. When the point substitution is ON, its value is not affected by changes in the field or by calculations, until point substitution is removed. Point substitution causes the value of a telemetered point (the receiving point) to be substituted with the value of another point (the source point), within the same domain. The source point can be telemetered, calculated or manual. The receiving and source points must be both analogue points, or be both digital points. Accumulator points are not allowed. The same source point can be substituted in any number of receiving points. But only one level of point substitution is allowed. Thus a point that is currently used as a source point cannot be a receiving point for another point substitution. The source point can be configured, or the operator can select it. Point substitution is applied/removed by the operator. Point substitution functions in a similar way to manual override (e.g. actions when applied/removed, operation of fascia, etc). Warning " This feature can be used to substitute control points, however, care is recommended because controls issued on substituted (receiving) points may not provide consistent feedback to the operator. Note: the Common Data Inhibit Mask for Substitute Point can be configured to inhibit controls if desired. When point substitution is applied, the source point ID is checked to be non-blank, of the correct type, currently accessible, and only one level of point substitution is allowed. Then: The point is flagged Substitute Point. The associated input is still scanned to update the bad data quality flags. An entry is made in the Administrative Tags List. An operator action event is generated.
When point substitution is removed: The Substitute Point flag is cleared from the point. The point is demand scanned. The related Administrative Tags List entry is deleted. An operator action event is generated.
The source point ID can be changed (or blanked) when point substitution is OFF.
2.7.3
Analogue Limits
Analogue points can have high and low alarm limits and flat line detection defined. The associated tuning parameters are accessed via the Analogue Limits Fascia.
Page 53 of 215
2 HMI
The fascia depicts a schematic alarm zone diagram for easy reference. The following attributes can be changed via the fascia. If an attribute is not configured for the point, the attribute cannot be changed. High alarm limit. Low alarm limit. High zone width (or critical high alarm limit). Low zone width (or critical low alarm limit). Inter zone deadband. Return zone deadband. Flat line time period. Flat line deadband.
The high and low zone exponents, and high and low engineering limits, are also displayed, but these cannot be changed via the fascia. The fascia also contains toggle buttons for the following alarm functions. If a function is not configured, or the limit is not configured, the button is insensitive and ghosted. High alarm limit inhibit/enable. Low alarm limit inhibit/enable. Better alarm inhibit/enable. Zone event inhibit/enable. Flat line enable/disable.
Alarm generation and management is described in Section 5. Several functions can be performed. The database is not affected until the Enter button is pressed. Operator action events are generated for attributes that have changed. Entering a value such that the point limits are inconsistent causes an error message to appear.
2 HMI
2.7.3.1
Function Buttons
Analogue Limits Fascia function buttons are as follows: Inhibit High Limit. Inhibit/enable the points high alarm limit (refer Section 5.8.2). When inhibited there is a red indication on the button. Inhibit Low Limit. Inhibit/enable the points low alarm limit (refer Section 5.8.3). When inhibited there is a red indication on the button. Inhibit Better Alarm. Inhibit/enable the points alarm generation when crossing to a better alarm zone (including exit alarm) (refer Section 5.8.4.2). When inhibited there is a red indication on the button. Inhibit Zone Event. Inhibit/enable the points better/worse event generation from alarm zone traversal (other than normal zone) (refer Section 6.6.2). When inhibited there is a red indication on the button. Enable Flat Line Alarm. Enable/disable the points flat line alarm functionality (refer Section 5.1.2). When enabled there is a red indication on the button.
2.8

Supervisory Control
A field device may be controlled remotely using the following types of supervisory control: Digital controls. Analogue momentary and scaled raise/lower controls. Analogue setpoint controls.
When supervisory control has been selected on a point, it is reserved for exclusive control. The runtime annotation character C appears next to the point. If within a pre-configured time (the control reserve time period, a system constant nominally set to 30 seconds), the Execute button has not been pressed; the control function automatically terminates and prompts an error message in the guidance message area. The point is released for another control operation. Pressing Cancel dismisses the fascia. The Cancel button, prior to pressing Execute cancels the control function. Exclusive control is then removed from the point. When a control, on a point with feedback monitoring, has been executed, the runtime annotation character A appears next to the point (i.e. indicates the point is under control and an authorized change is expected). A demand scan is initiated after a time delay. The delay is a percentage of the points fail-to-operate time (rounded up to the nearest second). The percentage delay is set by system constant and applies globally to the system. If the fail-to-operate timer expires before the expected change is detected, a fail-to-operate event is generated, an error message is displayed on the control fascia, and the authorized runtime annotation A is cleared. Changes after the fail-to-operate time are not considered to be authorized, and therefore are processed as for any other unexpected change of the point. Fail-to-operate times are configurable on a per point basis. For digital controls to the current state, in systems using DNP event scanning, a fail-to-operate event is usually generated (because there is no feedback from the RTU). If an error causes the control operation to terminate, an appropriate error message appears in the guidance message area. Error conditions include: Control reservation time expired. Control fail-to-operate. Controls inhibited. Failing to communicate to the remote station. Failing to communicate to Core SCADA.
Only one control can be in progress per RTU. Concurrent controls on different RTUs are permitted.
Page 55 of 215
2 HMI
2.8.1
Digital Controls
The Digital Control Fascia shows the current state of the point, with the allowed target state(s), and buttons for the control action. The new target state (that the point can be controlled to, opposite to the current state) is indicated by the Selected button (highlighted). The other button is blank. The text alongside the buttons is configurable for the point, and correspond to the control actions open and close. A point can be configured to allow control to the current state. The options are close to closed field device allowed and open to open field device allowed. Hence, both the Selected and Select buttons may be sensitive. Pressing a button to select the target state de-selects the other button. The new target state (that the point is to be controlled to) is indicated by the Selected button (highlighted).
The Execute button initiates the control sequence to the remote station (this is a two pass action, with check before operate sequence). If the control command is transmitted and successfully accepted by the remote station, then the runtime annotation character A appears next to the point. When the control succeeds and the point changes to the desired state then the authorized runtime annotation is cleared, and the fascia is dismissed. The user is informed if the point fails to change to the desired state, within the fail-to-operate time. Pressing Cancel dismisses the fascia. Optionally, the point can be configured not to monitor control for completion. In this case, there is no authorized change expected and the runtime annotation character A does not appear. For DNP protocol, the relay closure time is configurable on a per point basis (default is one second).
2.8.2
Analogue Momentary and Scaled Raise/Lower Controls
Raise and lower controls are achieved by a single action momentary closure of a pair of relays. One relay is for raise control and the other relay is for lower control. There are two types, momentary for a single length pulse output (e.g. for tap position control), and scaled for an operator selected step size (e.g. for generator output control). If the hardware does not support scaled raise/lower controls, the request is treated as momentary. Continuous raise/lower (button held down) is not currently supported.
Page 56 of 215
2 HMI
The Analogue Scaled Raise/Lower Control Fascia shows the current value of the point, with buttons for the control action. The Analogue Momentary Raise/Lower Control Fascia is similar, but without the step size selection. The direction of movement is selected by Raise and Lower. The step number buttons select the size of the raise/lower pulse. The current selection is indicated on the button. The pulse size is configurable on a per point basis. The desired control operation is selected. The Execute button initiates the control sequence to the remote station (this is a two pass action, with check before operate sequence). If the control command is transmitted and successfully accepted by the remote station, the fascia is dismissed, and the control reserved runtime annotation is cleared. There is no control feedback monitoring for raise/lower controls; this is the operators responsibility.
2.8.3
Analogue Setpoint Controls
A setpoint control outputs an absolute value to an analogue output. The setpoint value entered by the operator must be within the engineering control range. The setpoint value (in engineering units) is converted into a binary output value, which is sent to the RTU to activate the setpoint control. Each setpoint control point is configured with the engineering control minimum/maximum and respective output count minimum/maximum, for the linear conversion.
The Analogue Setpoint Control Fascia shows the points current value and setpoint value. The setpoint value is the desired value set by the operator or by an application. If the point is configured to monitor the control for completion, the current value must reach the setpoint value ( the tolerance factor, which is a configured system constant) within the fail-to-operate time, to be considered
2 HMI
successful. The desired setpoint value is entered. The Execute button initiates the control sequence to the remote station (this is a two pass action, with check before operate sequence). If the control command is transmitted and successfully accepted by the remote station, the runtime annotation character A appears next to the point. When the control succeeds and the point reaches the setpoint then the authorized runtime annotation is cleared, and the fascia is dismissed. The user is informed if the point fails to reach the setpoint, within the fail-to-operate time. Pressing Cancel dismisses the fascia. Optionally, the point can be configured not to monitor control for completion. In this case, there is no authorized change expected and the runtime annotation character A does not appear.
2.9
History
Retrieved historical data is displayed using the standard HMI DDOs (refer Section 2.5.2). Any stored attribute that is supported by the DDOs can be displayed (e.g. integers, floating point values, quality, time). The displays shown in this section are indicative only. Displays can be configured to suit specific projects, including: Background text can be modified, to be more meaningful for a particular application. Fields can be relocated on the display. A given field can be pre-defined, where a display has a specific purpose and it would be a nuisance for the user to have to enter a parameter, e.g. the Format field, the Domain field.
Field Details The fields on the history displays of particular interest are: Days from today Format This field will accept either, a number of days back in time from today, or a date in the form dd-mmm-yy (e.g. 25-nov-99). The Format field (if present) enables the user to enter the type of history request. This specifies the format for the returned data. For example, delta(1.0,0.5) would perform delta compression on the history data before returning the data. The Transform field (if present) enables the user to enter a transform for post retrieval execution on a history request. For example, ave(1sec,1min), would perform an average transform on the history data before returning the data.
Transform
The default setting depends on the particular type of display. Normally, the format default is fixed sample frequency data, where the time interval between samples is defined by the Display Interval field. The transform defaults to none (Note the default settings are independent of the default for the actual history request). Pre-Defined and Scratch Displays There are two methods of configuring a display for historical data, pre-defined and scratch (refer iSCADA System HMI Engineers Manual): 1. The pre-defined method provides a fixed history data configuration. It is achieved by specifying a specific historical data key in the read key of the DDO. 2. The scratch method allows the history data (e.g. times, objects, etc) to be selected while displayed. It is achieved by specifying a substitutable historical data key in the read key of the DDO. This is on a per console basis; the assignment is not seen by other screens/stations within the domain. Optionally, the selection can be made persistent, so that whenever the display is brought to the screen (of the same console), it remembers the last entered selection. For the scratch method to work, additional DDOs are configured to accept the users inputs (e.g. object name, start date/time, etc). From these inputs, the substitute key is converted into a specific historical data key, by the software. Hence, the same display and/or DDO can be used to display different historical data. Note that the error reporting on users input is performed on the constructed historical data key, not
Page 58 of 215
2 HMI
the individual DDOs. An error would result in a bad key message. Static and Moving Trend Displays History trends can be configured as either static or moving (refer iSCADA System HMI Engineers Manual): 1. A static trend display has a fixed start date/time, thus it always displays historical data for a time span starting from that fixed date/time, the trend does not move along the time axis. The start date/time trend can be entered by the user. 2. A moving trend display continually adjusts its start date/time to display current data as it occurs, thus it always displays historical data for a time span starting from the current date/time, causing the trend to move along the time axis.
2.9.1
Historical Trend
The historical trend is the most natural choice to present historical data, as values are plotted against time. The time indication on the horizontal scale (time axis) is presented in local time (refer Section 8.8). A maximum of eight curves can be trended by a trend DDO. All of the curves share the same time axis. Each curve can have its own vertical scale (Y axis). Each curve has its own colour. Several trend DDOs can be configured on a display. Digital state text values (i.e. the state of a multi-state object, e.g. open, close, etc) are automatically converted to their corresponding numeric values before they are trended. For samples that are in high/low alarm, have bad data quality, or some other quality flag set, the corresponding curve segment is shown with the colour, defined in the foreground value colour column of the runtime annotation table (refer Section 2.5.1). These colours are configurable on a system basis.
_historytrend4: Multi Pen Historical Trend
Dismiss
100.
CONFIGURABLE HIST-TREND
1 2 3 4 a i 0 1 a i 1 0 a i 1 1 a i 2 0
75.
50.
25.
0.0 10:00 11-Jun-99 9:00:00 11:00 12:00 13:00 14:00 15:00 11-Jun-99 15:45:00
Time of Day
Days from today: 1 Scale Min: Rescale Rescale Rescale Rescale 0.0 0.0 0.0 0.0 Scale Max: 100.0 100.0 100.0 100.0 Object Pen 1 ai01 Pen 2 ai10 Pen 3 ai11 Pen 4 ai20
Start at: 0900
Display Interval: 5min Transform
Attribute dpValue dpValue dpValue dpValue
The figures show typical historical trend display layouts for point objects. Note that they use the scratch display method. The additional text DDOs are used to accept users input such as point name, attribute, start date, start time, display interval, etc.
Page 59 of 215
2 HMI
2.9.1.1
Time Change Presentation

_historytrend1: Single Pen Historical Trend
Dismiss
100.
CONFIGURABLE HIST-TREND
1 m a n a 1
75.
50.
25.
0.0 0:30 10-Jul-99 0:15:00 0:45 1:00 1:15 1:30 1:45 2:00 2:15 10-Jul-99 2:30:00
Time of Day
Verticle Scale Min: 0.0 Max: 100.0 Use New Scales
Days from today: 0 Start at: 0015 Display Interval: 1min
Point: mana1 Attribute: dpValue Transform:
If there is a time change (e.g. for daylight saving time), the curve clearly shows when it happens by a forward or backward horizontal line. The following example shows a backward time change (e.g. when the time is wound backwards at the end of daylight saving time). The curve clearly shows when it happens by a backward horizontal line, which represents the back-trace for the overlapped time.
2.9.2
Operator Assignable Trend
The operator assignable trend function is an extension to the historical trend display facility. It enables an operator to select one or more points from a line diagram or system list, and assign those points to pens on an operator assignable trend display. Point selection is by mouse point and click. Both static and moving history trends can be configured. 2.9.2.1 Select Point for Trend
A point can be selected from any point display or system list. It is selected using the Assign Trend button on the point palette. Points are added to an internal trend list, which is then available for subsequent assignment on an Operator Assignable Trend Display, on a first-in-last-out basis. Eight entries are available in the trend list. If the trend list size is exceeded, the new point is entered in the trend list and the oldest point in the list is lost. If the selected point is not in history, the user is warned with a message, the user can either continue or cancel the selection. 2.9.2.2 Operator Assignable Trend Display
The Operator Assignable Trend Display is similar to a normal historical trend display, with addition of the following: Assign Point. Clear Point. Quick Navigation.
The operator may enter the title of the trend. The title is maintained when reopening a closed display.
Page 60 of 215
2 HMI
R5_asgntrend: Operatable Assignable Trend

Dismiss
100. This is an Operatable Assignable Trend. You can enter the trend title here.
1 2 3 4 a i 0 1 a i 1 0 a i 1 1 a i 2 0
75.
50.
25.
0.0 10:00 11-Jun-01 9:00:00 11:00 12:00 13:00 14:00 15:00 11-Jun-01 15:45:00
Time of Day
Point ID Domain Days from today: Start at: Display Interval:
Quick Navigation Controls
Assign #1 Assign #2 Assign #3 Assign #4
Clear #1 Clear #2 Clear #3 Clear #4
Pen 1 ana301 Pen 2 ai1 Pen 3 ai2 Pen 4 ana304
1 0900 5min
per 1 per 60
day(s) minute(s)
Assign ALL
Clear ALL
Assign Point Assign Point associates a point from the trend list with the corresponding pen number and activates the tracing of the point. A y-axis is added for the nominated point in the corresponding colour and with the correct scaling. Points can be assigned either individually or all at once. The Assign button pops the newest point from the trend list and associates it with the corresponding pen. The Assign All button pops all points from the trend list and associates them with the pens. The oldest point from the trend list is assigned to pen number 1, the next to pen number 2, similarly for up to 8 points that are in the list. Thus for 5 points in the trend list, these are assigned to trend pens number 1 to 5, with the remaining pens left with their previous assignments. Note that the order of assignment is the opposite of that for individual assignment. Assigned points are removed from the trend list. The corresponding point ID field is updated to contain the name of the point. Upon assigning an analog point to a trend, a y-axis is added with the correct scaling for the upper and lower engineering limits of the point. Upon assigning a digital point to a trend, a y-axis is added with the correct scaling for digital states that the point has during the period of the display. For a point that transitions from 1 to 2, the scale will be from 1 to 2. For a point that only has a value of 1, the scale will be from 0.5 to 1.5. The trend window displays an x-y trend of the point in the same pen colour as the point name and the y-axis. The x-axis is scaled from the date/time currently selected. The x-axis scale may be changed. Clear Point Clear Point disassociates the point from the corresponding pen number and deactivates the tracing of the point. Assigned points can be cleared individually or all at once. The Clear button disassociates the point from the corresponding pen number. The Clear All button disassociates all points from the trend pens. The y-axis for the point is removed from the display. The corresponding point ID field is cleared. Quick Navigation
Page 61 of 215
2 HMI
Quick navigation allows the user to quickly change the x-axis (time) parameters of the trend display. Buttons are provided for incrementing/decrementing the days and hours/minutes. The deltas are enterable. The left and right arrow date buttons change the date backwards and forwards respectively, by a set number of Days Delta per click. This operation changes the value in the Days From Today field in the corresponding direction. The left and right arrow time buttons change the time backwards and forwards respectively, by a set number of Time Delta per click. This operation changes the value in the Time field in the corresponding direction. When the time exceeds the end of day, it is rolled over into the next day and the date is moved forward. Similarly for decrement to the previous day. The Days From Today value does not go negative. Subsequent clicks on either the right arrow date or time buttons are ignored. The Days Delta field is enterable as a number in days, from 1 to 100. The Time Delta field is enterable as a number in minutes, from 1 to 999. The Trend Display is immediately changed to reflect the new settings.
2.9.3
Historical Plot
A historical plot is used to display the relationship between two historical points over a time period. A maximum of eight curves can be plotted in a plot DDO. All of the curves share the same point on the X-axis, with the same horizontal scale. Each curve can have its own vertical scale (Y axis). Several plot DDOs can be configured on a display. Digital state text values (i.e. the state of a multi-state object, e.g. open, close, etc) are automatically converted to their corresponding numeric values before they are trended. For samples that have bad quality, the corresponding curve segment is shown with a bad colour. The bad colour is configurable on a system basis. A typical historical plot display for point objects is shown. Note that it uses the scratch display method. The additional text DDOs are used to accept users input such as point name, attribute, start date, start time, display interval, etc. Note that the curves share the same start/end time.
_historyplot4: Multi Pen Historical Plot
Dismiss
100.
1 2 3 4 a i 0 1 a i 1 0 a i 1 1 a i 2 0
75.
50.
25.
0.0 0 10 20 30 40 50 60
ct100
Object Scale Min: Rescale Rescale Rescale Rescale 0.0 0.0 0.0 0.0 Scale Max: 100.0 100.0 100.0 100.0 X Direction ct100 Pen 1 ai01 Pen 2 ai10 Pen 3 ai11 Pen 4 ai20
Attribute dpValue dpValue dpValue dpValue dpValue
Date
Time
Display Interval
0 0 0 0
0900 0900 0900 0900
5min 5min 5min 5min
A historical plot display can be configured for a specific purpose. Note that it uses the scratch display
2 HMI
method to some degree, i.e. the point names are fixed, but additional text DDOs are used to accept users input such as start date/time and sample interval.
_genplot2: Generator #1 Time Based Comparison
Dismiss
100.0 200.0
BOILER PARAMETERS
F U E L C O S T
P R E S S U R E
0.0
0.0 -25:00 0:00 25:00 50:00 75:00 100:00 125:00
Temperature DegC
UNIT 1 COST OF SOLID FUEL UNIT 1 BOILER PRESSURE
vs vs
BOILER TEMPERATURE BOILER TEMPERATURE
Profile #1 Days from today: 0 Start at: 1900 Display Interval: 10min
Profile #2 1 1900 10min
By re-organizing the key configuration, it is possible to specify a different start time for each curve, therefore covering a different period. This provides a good visual comparison between a set of variables over different time periods. For example, the user can compare the plot of fuel cost and pressure against temperature between two days. Notes: A different colour can be used for the different period. Each curves parameters (e.g. start date/time, sample interval, etc) can be different for extra flexibility. The X and Y-axis are always located at the bottom and left side respectively, even if data is negative, i.e. a mid-crossing X and Y-axis is not supported.
2.9.4
Historical Tabular
A historical tabular display is used to present historical data in a tabular form. Point values (with quality) are listed against time. Where the type of data requested returns data at a fixed frequency (e.g. interpolated history data and most transforms), several data columns can share the same time column and scroll bar. For this case, up to eight data columns are supported, with one time column and one scroll bar for an integrated historical tabular presentation. Other types of data requests (e.g. raw history data, delta compressed data) return samples at various times and therefore each data column needs its own time column and scroll bar. Several integrated historical tabular presentations can be configured on a display.
Page 63 of 215
2 HMI
_historytab3: Multi Historical Tabular Data

Dismiss
Total samples 1000 Object vr105 Attribute dpValue Start Date/Time 0 1300 vr106 dpValue 0 1300 Display Interval 1min vr107 dpValue 0 1300
Reply Format sample(1min) Reply Transform
sample(1min)
sample(1min)
DATE/TIME 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 0900:00 0901:00 0902:00 0903:00 0904:00 0905:00 0906:00 0907:00 0908:00 0909:00 0910:00 0911:00 0912:00 0913:00 0914:00 0915:00 0916:00 0917:00 0918:00 0919:00
VALUE 7.36 7.53 7.36 7.36 7.38 7.56 8.78 8.16 7.12 9.56 7.30 7.06 8.86 7.46 6.36 7.34 7.56 7.66 7.34 7.36
VALUE 17.36 17.53 17.36 17.36 17.38 17.56 28.78 28.16 27.12 29.56 17.30 17.06 18.86 17.46 16.36 16.36 16.36 16.36 27.34 27.36
VALUE 87.36 87.53 87.36 77.36 77.38 77.56 78.78 88.16 87.12 89.56 77.30 77.06 78.86 77.46 86.36 77.34 77.56 77.66 77.34 77.36
B B B
M M M M
Point value/status is displayed in either numeric form for analogues, or in status text form for digitals. Note that digital point values can also use numeric DDOs, which display the value 0, 1, 2, etc, depending on the points state. The DDO can be configured to show the associated runtime annotation displayed as two characters alongside the value/status. This runtime annotation represents the history data quality. Missing data appears with the same runtime annotation as input bad. The point value/status is colour coded according to the runtime annotation. A typical historical tabular display layout for point objects is shown. Note that it uses the scratch display method. The additional text DDOs are used to accept users input such as point name, attribute, start date, start time, display interval, etc. A normal DDO can be used to display the engineering units of the point. Each integrated historical tabular presentation is configured using several separate multi-value DDOs. The multi-value DDO is a simple DDO that accepts multiple integer or real values, and displays them in a column (arranged in chronological order). A typical historical tabular display consists of: A custom time DDO used for displaying the timestamps (in local time). Several numeric DDOs (real or integer) for displaying analogue point values, or text DDOs for displaying digital point states. An optional scroll DDO for controlling the display of timestamps and values/states.
All columns must be contain a non-blank valid point name, for the display to function correctly. 2.9.4.1 Change Only Presentation
Change only historical requests are particularly useful for digital points, where the status only changes occasionally, and such changes are difficult to find over a large time period of fixed samples. An example historical tabular display using change-only data for a digital point is shown.
Page 64 of 215
2 HMI
_historytab1: Single Historical Tabular Data

Dismiss Object st105 Attribute dpValue Start Date/Time 0 Display Interval 1min Reply Format raw() Reply Transform DATE/TIME 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 10-Sep-99 1400:12 1427:32 1504:53 1531:23 1532:44 1535:59 1550:28 1559:47 1628:22 1644:41 1658:27 1722:28 1725:47 1810:55 1812:37 1814:41 1819:32 1823:51 1834:19 1846:27 STATE OPEN CLOSE OPEN CLOSE CLOSE CLOSE CLOSE OPEN CLOSE OPEN CLOSE OPEN CLOSE OPEN OPEN OPEN OPEN OPEN OPEN OPEN 1300 Total samples 400
B M
T1 T1 S
2.9.4.2
Time Change Presentation
If there is a time change (e.g. for daylight saving time), the displayed time stamps clearly show it by going forward or back in time.
2.9.5
History Data Editing
Under certain circumstances, such as transducer failure or loss of RTU communications, invalid data may have been collected and stored in the history database. The user may obtain correct data from other sources and may wish to amend the stored data. To do this, a function called History Edit is available. History Edit allows data to be edited in the distributed history storage (uncompressed or compressed). Edited data replaces the original data for the edit time span, and is flagged as Edited History quality. Data that has been archived cannot be changed directly, but may be changed in the distributed history storage and then manually re-archived. Retrievals automatically return any edited data that exists for the request period. After data has been edited, any subsequent retrieval transforms, calculations, etc. automatically use the modified information. However, any previous retrieval transforms, calculations, etc., which were made using the original data as source cannot be corrected. These can only be corrected manually. Selection of this function invokes the History Data Edit Window. The user enters the point name, start date/time and display interval.
Page 65 of 215
2 HMI
_hsedit: History Data Edit

Dismiss Object: ana1 Start date/time: 18-jun-99 0900
Display Interval: 1min Date/Time 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 18-Jun-99 0900:00 0901:00 0902:00 0903:00 0904:00 0905:00 0906:00 0907:00 0908:00 0909:00 0910:00 0911:00 0912:00 0913:00 0914:00 0915:00 0916:00 0917:00 0918:00 0919:00 0920:00 0921:00 0922:00 0923:00 0924:00 0925:00 0926:00 0927:00 0928:00 0929:00 Value 7.36 7.53 7.36 7.36 7.36 7.40 7.50 7.60 7.70 7.80 7.90 7.90 7.87 8.25 8.78 8.16 7.12 9.56 7.30 7.06 8.86 7.46 6.36 7.34 9.56 7.30 7.06 8.86 7.36 7.38
B B EH EH EH EH EH EH EH
edited history (eg point was bad but user knew what the field values were).
Enter
Reset
The window then displays 30 values in tabular form. There is no scroll capability. The values show the current history data for the point. This data may or may not have been already edited. The display interval can be any period that the user specifies. It does not have to be related to the current storage period of the historical data. For a 1-second interval the window should be reconfigured for at least 60 values, or the time field extended by 2 characters to include seconds. The user enters new values in the value field. The bottom row displayed value cannot be edited. When satisfied the values are correct, the Enter button is selected to implement the edit to the historical database. The entered value applies for the whole display interval starting from the time against the entered value field until (but not including) the next time. All raw values within this period are changed. Values in the future can be entered but will be replaced by collected data. The Reset button can be used to cancel the values entered in the window (i.e. before an Enter is done). The window values are restored with the current values from history.
2.9.6
2.9.6.1
History Utilities
History Storage Statistics
The History Storage Statistics display provides an analysis of the history storage utilization for distributed history. 2.9.6.2 History Services
The History Services display provides for history maintenance. The Information field allows all history objects or a single history object to be selected.
Page 66 of 215
2 HMI
2.10
History and Event Archive
Event and history files are archived to the same DVD RAM disc. The Archive Management Data Display provides management of history file archival/retrieval between disc and DVD RAM. Some functions are also applicable for event file archival/retrieval.
2.10.1
Archival
The Archive Management Data Display shows the status of the history file archive list that is used to keep track of outstanding history archive jobs. After a job has been completed, the corresponding entry is deleted from the list. An alarm point can be configured to indicate when the local disc area becomes full, and no archive files can be deleted to make room for a new archive file to be built (i.e. due to a long absence of the optical disk). The Archived File button on the Event List provides a list of all archive files available for selection (including those on DVD RAM). Refer Section 6.7 for information on event storage and event file archival.
_archivemgt: Archive Management Data
Dismiss Archive List Date 09 02 26 19 03 26 Jun Jun May May Dec Nov 1999 1999 1999 1999 1998 1998 Archive Station jupi5 Total Lines 100 Status Outstanding Outstanding Outstanding In Progress Outstanding Outstanding
Local Disc Statistics Status Optical Disc % Full
Drive
0 Statistics % Full Dismount Format
Current Volume ID XYZGAS00101 Set Volume ID XYZGAS00103
Set
Mount
Error/Status Message
Retrieval (copy from Optical to Local disc) Start Date/Time End Date/Time Status 12 Jan 99 14 00 30 Jan 99 12 00 Retrieve Cancel
History file archiving is initiated automatically. The software checks the volume identification of the disc currently mounted in the drive. If it is different from the registered identification, archiving does not occur. This ensures that the registered DVD RAM disc holds history/events for consecutive archive periods. The operator is made aware of impending overflow of the DVD RAM disc by a %full indicator on the Archive Management Data display. If the DVD RAM disc is full, archiving does not take place, the archive jobs remain in the archive list, and an event is generated. An alarm point can also be configured to indicate the DVD RAM disc full condition. The displayed DVD RAM disc statistics (e.g. space used, free) includes events and history together.
2 HMI
The user should keep a manual record of the archive DVD RAM disc contents, typically with each DVD RAM disc, after the disc is full and removed from the system. The following buttons are provided on the Archive Management Data display: The Local Disc Statistics button invokes the Local Disc Archive Statistics display. The Optical Disc Statistics button invokes the Optical Disc Archive Statistics display. The Set button mounts a DVD RAM disc as the disc to use for history/event file archiving. This causes the volume identification to be read and registered. The Mount button (for history/event files) is used to: Mount an old archive disc to run queries from it. Re-mount the disc currently registered for archiving (e.g. after a retrieval has been performed from an old archive disc). Mount an already filled archived disc for re-archiving edited history. The Dismount button (for history/event files) dismounts the DVD RAM disc from the drive. The Format button formats a blank DVD RAM disc for history/event file archiving. When it is invoked, the user is prompted to enter the volume identification to uniquely identify the disc. Volume identification can be up to 8 characters long. For optical media with two sides (e.g. a double sided DVD RAM) each side is treated as one volume. To use both sides of the disc, operator intervention is needed to turn it over when one side is full, and to format the side and enter another volume identification.
2.10.2
Retrieval
The Archive Management Data Display allows selected history archive files to be restored from DVD RAM disc to the local disc. This may be used for running queries directly from the local disc (rather than from DVD RAM), and after disc replacement (i.e. due to a fault). The Archived File button on the Event List allows event archive files to be accessed. The Archive Management Data Display does not handle event archive files. If the history storage space on the disc is full, the oldest archive file on disc is replaced with the restored archive file (provided that archive file on disc has been archived to DVD RAM). To retrieve one or more history archive files from DVD RAM to disc, the user: Mounts the appropriate DVD RAM disc. Enters the start and end dates for the period of interest. Selects the Retrieve button to initiate retrieval. The Cancel button cancels any retrieval that is currently in progress.
The start and end dates can span more than one archive file, provided they are all on the same DVD RAM disc. The dates do not have to correspond with the actual archive period start/end dates (e.g. if the archive period is weekly, then the retrieval start and end dates could both be 12 Nov 99 to retrieve the archive file that covers that day). The Status field indicates that the retrieval is in progress.
2.11
History Replay
The operator console operates in either of two modes: 1. Normal Mode where all displays show realtime data. 2. History Replay Console Mode where the particular displays show data from history replay.
2.11.1
History Replay Console Mode
History Replay Console Mode is initiated via the History Replay Mode button on the General System Displays Window. The operator is then prompted to select the time range, and the console enters the History Replay Console Mode.
2 HMI
When the console is in the History Replay Console Mode, the History Replay Console Mode Command Window replaces the normal Command Window. In the upper right hand corner of the command window, the words HISTORY REPLAY are shown flashing in the normal position that the time is displayed, to give the user a clear indication of the mode.
Fast Run Toggle Direction Set Times
Indication of current replay action here
2.11.2
Time Range Selection
When History Replay Console Mode is initiated, the Time Range Selection fascia allows the operator to choose whether the time range is to be that of a selected disturbance, or a user selected time range. 2.11.2.1 Selected Disturbance
The ability to select a disturbance gives the operator quick access to target sections of data in history. Disturbance Logging is a History System facility (refer Section 10.1.2). The user configures disturbance triggers, with pre and post disturbance periods. A disturbance trigger is a specific state transition of a given digital point. The Disturbance Selection Menu lists all disturbances that the history system is aware of, including any on the mounted history archive DVD RAM disc. Clicking on a trigger point lists all disturbances that the history system is aware of, for that point. The user selects the desired disturbance. The number of seconds for the step operation (range 1 to 300 secs) is entered. The default is 5 secs. The time multiplier for the fast forward operation (range 1 to 300) is entered. The default is 60. Pressing a button on the Disturbance Selection Menu initiates the History Replay Console Mode. The console replay clock is set to the disturbance start time and stopped state. The list of disturbances is only available on HMI stations that have history online, or on HMI stations that are connected to a station with history online. 2.11.2.2 User Selected Time Range
To manually select a time range, the user invokes the Set Time Range Menu. The desired replay start and stop times are entered. The time range can be any time period that is included in History; it is not limited to disturbance periods. The default start and end time is set up for the last one hour period of current real time. The desired Initial Time is entered. The default is half way between the start and end time. The Time Step and Fast Multiplier fields are as described in Section 2.11.2.1. Pressing a button on the Set Time Range Menu initiates the History Replay Console Mode. The console replay clock is set to the Initial Time and stopped state.
2.11.3
Running in History Replay Console Mode
The History Replay Console Mode Command Window (Section 2.11.1) provides the following set of command buttons to control History Replay operation. This allows the operator to control the speed and state of the replay. An Indication of current replay action is shown on the Command Window. Rewind Stop Step Rewind the replay clock to the start time. Freeze the replay clock at the currently displayed time. Advance the replay clock by a single Time Step selected number of seconds in the current clock direction.
Page 69 of 215
2 HMI
Run Fast Run Toggle Direction Select Normal Mode
Replay at normal speed in the current clock direction. Replay at an increased selected speed (Fast Multiplier) in the current clock direction. The exact speed is approximate. Changes clock direction, forward to backward, and backward to forward. Exit replay mode.
The replay clock does not advance past the end time, or before the start time. If either of these limits is reached, the replay clock is set to the limit and replay is stopped. The replay clock, which reflects the current replay date and time, is displayed. The replay start and end times are also displayed. The normal real time clock is not displayed. The Set Times button invokes the Time Range Selection fascia, that allows the operator to select a new replay time range via the Set Time Range Menu or the Disturbance Selection Menu. On single screen consoles the audible alarm annunciator is de-activated while the console is in the History Replay Console Mode. For multi screen consoles the audible alarm annunciator is only deactivated when the first screen is in the History Replay Console Mode. Running history replay on other screens does not de-activate the audible alarm annunciator. History Replay Console Mode has its own set of Permit Tables (user permissions/privileges) per user class. These may be different to the same user class when in Normal Mode. The permit tables should be set up to prevent the operator from issuing controls while in History Replay Console Mode.
2.11.4
Data Displays in History Replay Console Mode
During History Replay Console Mode all point and event data is obtained from history and event storage for the current replay time. All point and event displays are available to the operator and show the replay data. The user can mount a DVD RAM disc that contains the history and event data for the replay time range. The software reads data from the DVD RAM disc (as necessary), without user intervention, even if the data spans consecutive history or event files (e.g. the replay period may include midnight, which spans 2 daily event files). The Event List operates in the mode that treats the online event files as separate files (refer Section 2.6.2.2). Thus when the time moves into a new file time period, the Event List display is blank, until the first event in the period is encountered. The Event List buttons for manually selecting files (i.e. Archive Files, Oldest File, Current File, Arrow, and 0 buttons) are disabled in replay mode. The Event List can be filtered using the Filter Fascia. However, time filtering is not available in History Replay Console Mode. Alarms are not replayed. However, the event list shows the events that are associated with alarms. Point displays only show the runtime annotation for the quality flags that are stored in history. This may show the alarm state depending on which flags are present and their display priority. Refer Section 10.1.4, for description of quality flag storage in history. Refer Section 2.5.1 for runtime annotation display priority. The palette display normally available when a point value is selected is disabled in replay mode. Any attributes configured for history collection can be displayed. Attributes that are not configured for history collection, that are configured to be displayed with their runtime annotation, shows a runtime annotation of not supported (NS) while in replay mode. If there is no data in history for the replay clock time then point data shows as bad data. If there is no event data for the period from the start time to the replay clock time then the Event List is blank. There are no buttons on the History Replay Console Mode Command window to invoke the Alarm, Off-Normals or Tags List. However, any of these lists that were displayed when replay is initiated continue to show realtime data, not replay data. The 3-Most Recent Alarms Window is blanked. All other displays, including history, communications, network, etc, show realtime data.
Page 70 of 215
2 HMI
If the Send Screen function is used, to send a display from one screen to another screen, the display appears on the destination screen according to the mode of the destination screen (regardless of the source screen mode)
2.11.5
Normal Console Mode
On exit from History Replay Console Mode, the normal Command Window replaces the History Replay Console Mode Command Window. The displayed time shows the real time. All currently open displays remain, but are updated with real data. The audible alarm annunciator is activated.
2.12
2.12.1
Server Access
HMI Station Console Assignment
The HMI Station Console Assignment Display shows the users that are logged into the selected Solaris HMI Station (Host).
2.12.2
Solaris Databaseless and Windows NT/2000 Servers Overview
The Solaris Databaseless and Windows NT/2000 HMI Station Servers Overview presents a summary of Solaris stations that are able to serve data, in all domains. Also shown for each station is the network connection status, which is the physical connection status obtained independently from the database server. This may be different from the connection status shown in Solaris Stations Network Overview, which is the status from the database servers perspective. Clicking on the Solaris Databaseless or Windows NT/2000 HMI Station icon displays the Server List Window that shows information about the servers available in the domain. Clicking on a Solaris station icon, displays the Database and Service List Window that shows information about available databases on that Solaris station. The Solaris station can be restarted via this window.
2.12.3
Database Server User List
The Database Server User List shows a list of users (user login name and HMI Station) that are connected to the selected database server station.
2.12.4
Changing Domain
Clicking on the domain name shown in the command window, and choosing from the Domain Selection List changes the database domain. Once selected, data for all windows is retrieved from the server of the selected domain. After a domain is selected, the list of available servers is updated accordingly. The default server is the last one selected in that domain, else the first one available in the server list of the domain.
2.12.5
Changing Database Server
Clicking on the database server station name shown in the command window, and choosing from the Server Selection List changes the database server station for the HMI Station (includes Database HMI Stations). Once selected, data for all windows is retrieved from the selected server station. The list of servers for the HMI Station is specified using the iSCADA Server Configurator. Each server is a network and server combination. Thus with a dual network, the entries for say vv3 could be vv3net1 and vv3net2. Both selections have the same effect in that they connect to vv3. If the chosen server does not have a realtime database running online then data in the opened windows is shown with an error indicator if possible, else is empty.
2.12.6
Changing User Class
For a user who belongs to more than one user class, clicking on the user class shown in the command
2 HMI
window, and choosing from the User Class Selection List, changes the user class that the user is logged on as.
2.13
2.13.1
2.13.1.1
System Management
Database Management
Database List
The Database List shows all the databases, and their status, for a given Solaris station. 2.13.1.2 Process Monitor
The Process Monitor Display shows all the databases and their status, and allows a user to load/unload databases, for a given Solaris station. The window can be called up via the database name on the command window, or via the change button on the Database List. Any of its database servers can be selected by clicking on the server field, and choosing from the pop-up menu. Similarly, another domain can be selected via the domain field. The Default Database is the database that is normally accessed by the HMI (on this station). It is default in the sense that display components, that do not specify a database name, will use this database.
2.13.2
2.13.2.1
Station/Network Management
Solaris Stations Network Overview
The Solaris Stations Network Overview presents the operator with a summary of Solaris stations on the local network and the status of each from the database's perspective. Also shown for each station is the network connection status. Solaris stations can be restarted via this window. The display is customized for each given project. The window contains the following data for each station: Station Name - This station the user is on, is highlighted with a green border. Station Status - The following states are possible: UNIX Online Fail - The UNIX operating system is resident, but station is not online. - Fully online operational station. - The station has failed.
Network Connection Status - The following symbols are used: Solid Green Box Red X - Network connection OK. - Network connection failed/unavailable.
The following functions are available for each station, via the station palette: Load & Go - Reboot the station, and restart any databases that were running before the reboot (with the same attributes they were originally started with). Load - Reboot the station, but do not restart any databases that were running before the reboot. Warm Start - Restart the current realtime database with the same attributes it was originally started with (e.g. telemetry feed, default database, etc). Network Statistics
2.13.2.2
The Network Statistics Display shows station and network performance statistics for Solaris stations from the database's perspective. The user can determine the load put on the network by each Solaris station. The statistics are updated every 10 seconds, the update process is started and stopped by the operator. A certain level of errors is to be expected as stations are brought online or shutdown, but after the
2 HMI
system is stable, the operator can reset the statistics and then monitor the level of errors.
2.13.3
2.13.3.1
Communications Management
Communications Overview
The Communications Overview display shows the status of FEP stations, communication channels, routes, and RTUs. Further information for each, can be brought to the screen by clicking on the item of interest. The display is customized for each given project. 2.13.3.2 Channel Status
The Channel Status display shows the status of the communication channel, buttons to put the channel in/out service, and a button to access the channel statistics display. 2.13.3.3 Route Status
The Route Status display shows the status of the communication route, buttons to put the route in/out service, and a button to access the route statistics display. 2.13.3.4 RTU Status
The RTU Status display shows the status of the RTU, with buttons to put the RTU in/out of scan, and on/off test, and a button to access the RTU statistics display. 2.13.3.5 RTU Administrative Functions
The RTU Administrative buttons cause the following action: Take RTU Out Of Scan All points belonging to the RTU are flagged RTU out of scan. The points belonging to the RTU are not entered in the Administrative Tags List. The FEP stops communicating with the RTU. A RTU Out of Scan event is generated.
Put RTU Into Scan All points belonging to the RTU have their RTU out of scan flag cleared. The FEP initiates time synchronization with the RTU (Section 3.4.4.2). For DNP and IEC101, the whole RTU is scanned, and updates the points (Section 3.4.4.2). For poll type protocols (e.g. Conitel, Modbus), the point is updated on the next scan. A RTU Into Scan event is generated.
Put RTU On Test All points belonging to the RTU are flagged RTU on test. The points are not entered in the Administrative Tags List. A RTU On Test event is generated.
Take RTU Off Test All points belonging to the RTU have their RTU on test flag cleared. A RTU Off Test event is generated. Communications Statistics
2.13.3.6
There is a Communications Statistics display for each FEP channel, route and RTU on the system. The display shows statistics on good and error communications (such as number of requests sent, error requests, bytes transmitted, scan overruns, timeouts, etc), over this minute, last minute, today, yesterday and as a total. All totals can be reset. All counts can be reset. Refer Section 3.6.
Page 73 of 215
2 HMI
2.13.4
Application Management
Applications are software components that augment the basic functionality of the iSCADA System. Typical packages include Dynamic Network Colouring (DNC), Real-Time Interface (RTI), and customer application programs. Applications need not interface to the iSCADA System via DAPI, OIL or any other specific API. Applications management provides: Process management: manual/automatic starting, failure monitoring, restarting and stopping of application processes. All running applications are stopped automatically at database shutdown. Application log file management: for recording the log output of each application. Current and previous log files are maintained. Event generation to record process management actions and application failures. A record is also kept in the Process Monitor log file.
The following limitations apply: Applications must run on a database station (e.g. not on a databaseless HMI station). Applications must be able to be started/stopped from a script file using standard UNIX facilities (e.g. not via an applications programming interface). Only non-interactive daemon-style applications are supported. GUI applications are not supported. The return value from executing an application is not used to determine failure. Redundancy is not supported. No special action is taken in response to changes in conditions of another station, such as database stops and starts.
Application programs are made known to the iSCADA System via the following file directories (refer iSCADA System Solaris Software Installation Manual): 1. A program directory that holds script files for starting and stopping application processes. Options: Whether the process should be restarted after it fails, and if so the grace period that must elapse between valid restarts. If a database name is not provided, the default database is used.
2. An auto start directory that indicates the application processes in the program directory that are to be started automatically at a database start. Options: Start process before starting iSCADA. Start process after starting iSCADA. The delay period to when processes are started is specified by one parameter common for all applications, configured in a system startup file.
No assumptions can be made on the relative startup order of the applications specified in the auto start directory. If a particular startup order is required then it must be coordinated amongst applications themselves (e.g. via staggering a start wait time). Application Program Status List The Application Program Status List shows the process identification and status of each iSCADA application program running against the default realtime database on the local station. From this display a given process may be started or stopped, and its log file be invoked. The window also contains the following: AutoStart - Indicates whether the program is to be started automatically at a database start: Before - start process before starting iSCADA. After - start process after starting iSCADA. None - not automatically started.
Failed - Indicates either: The program has failed to start within the grace period, and is no longer available for automatic restart or manual start. The script is moved to a failed directory (apps/failed). Manual intervention by the Engineer is necessary to move the failed script from apps/failed back to apps/progs. Or, the program has failed during normal running. It is still available for automatic restart or
Page 74 of 215
2 HMI
manual start. Auto Restart - Indicates whether the program should be automatically restarted if it fails. Grace Period - Time in seconds, for: Time that the program should start in. If the application fails to start within the grace period, it is marked as failed. Also the period that must elapse between valid restarts.
Start/Stop - This toggle button indicates if the application is running. It also allows the program to be manually started and stopped. Notes: The toggle button is disabled if the application fails to start. When starting an application, the Auto Restart feature can be disabled/enabled, and the grace period can be specified. Stopping an application that is configured to be auto start causes the auto start to be disabled.
2.14
HMI Station Logging
For a Solaris HMI Station, hard copy output is directed to a main/backup printer pair, of either the local printer, a printer attached to another Solaris HMI station, or a printer on the LAN. Output cannot be directed to a Windows NT/2000 HMI Station printer. For a Windows NT/2000 HMI Station, hard copy output can be configured to print on a printer attached to the PC, or on a printer attached to a Solaris HMI station, or printer on the LAN that is managed by the Solaris HMI station. The HMI Station includes the following logging packages: Print Screen and Print Window (i.e. Display Copy). Foreground Log. Event Logging (Incident and Periodic) (Solaris HMI Station). Reports.
2.14.1
Printer Summary
There is a Printer Summary for each Solaris HMI Station. It provides in/out of service information for all printers on the system. Fascias called up from this window allow the user to fail/restore each printer, and also to enter printer names for both the main and backup printer, for each of Display Copy/Reports, Incident Event Log, and Periodic Event Logs. Output can be directed to any system printer. Normally the station's own printer is used to reduce network activity. If a printer fails, runs out of paper, or is taken off-line, then an event is generated. If the printer is not back online within five minutes, it is automatically taken out of service. If a backup printer exists and is in-service, all output is then directed to the backup printer until the main printer returns to service. If both the main and backup have failed, the output is discarded. The logging on all the Solaris HMI Stations is independent. For example, one HMI Station can be configured to produce an incident log of area 1 events, whilst another produces an incident log of area 2 events on a different printer.
2.14.2
2.14.2.1
Print Screen and Print Window

Solaris HMI Station
This function captures an image of a screen or the selected window into a postscript file, and directs it to the assigned printer. If the printer is free, the printout starts immediately; otherwise it is left in the print queue. The postscript file is deleted after it has been printed. There is no limit on the number of print jobs in the queue, however the user should be aware of the disc storage usage. Postscript files are usually quite large, often in the order of 100K-1Mbytes per file. The output printer must be fitted with a postscript interpreter. A colour hardcopy can be obtained if the laser printer has colour printing capability.
2 HMI
2.14.2.2
Windows NT/2000 HMI Station
SAMMI provides a built-in utility that can snapshot a window for printing. Print preview is allowed.
2.14.3
2.14.3.1
Foreground Log
Solaris HMI Station
A Foreground Log supplements the Print Window function. It contains information on each database point in the window and the notes associated with the window. The log is usually printed on the next page following the display copy of Print Window. The Foreground Log feature does not apply to the report function (Section 2.14.5). For each database point the Foreground Log contains the display coordinates (line/column, in pixels relative to the origin of the window), point description, current digital status text, or current analogue value, at the time of snapshot. For trend displays the Foreground Log produces a tabular output of all the data items displayed on the trend, with the date, time and value of each pen. The log is enabled and disabled by toggling the Foreground Log Enable/Disable button in the General System Displays window. This enables or disables the Foreground Log for all screens on the console. The Print Window and Foreground Log are two separate print jobs. If a printer failure occurs while printing the Foreground Log, the printout may be directed to the backup printer. 2.14.3.2 Windows NT/2000 HMI Station
The Foreground Log allows examination of display component configuration in a notepad window. There is a print option in the notepad application.
2.14.4
Event Logging (Solaris HMI Station)
Each Solaris HMI Station can print incident logs and periodic logs. The configuration of these logs is described in the iSCADA System HMI Engineers Manual. 2.14.4.1 Incident Event Log (Solaris HMI Station)
Events are printed almost as they occur, with only a short delay to ensure chronological ordering. The log is printed in black and white. The incident log can be disabled online. If a laser printer is being used, it is recommended that a periodic log be used instead of an incident log; this ensures that each page is filled with events. Otherwise, the laser printer outputs a whole page each time it prints one or more events. Each Solaris HMI Station has an event filter mask for the incident log that is used to determine which events are to be printed on the log (similar to event filtering for the Events display). 2.14.4.2 Periodic Event Log (Solaris HMI Station)
Events are stored on disc and can be output to the printer at defined times. A periodic log would typically be set to print at the end of each operator shift. However, the frequency of the periodic logger should be higher for a high event rate and small event file size, to avoid retrieving large amounts of event records across multiple event files, with a corresponding reduction in performance. For each Solaris HMI Station, up to six separate periodic logs can be configured. Each log has its own event filter mask, log title, and up to six times per day when it is printed. The event filter mask is used to determine which events are to be printed on the log (similar to event filtering for the Events display).
2.14.5
Reports
The Report function prints a display or series of displays with customized report layout. The report is defined online using the Report Definition Form. It can be used in conjunction with the Task/Report Scheduler to print reports periodically. Reports can also be printed on demand. At least one user must be logged on to Sammi for the Report function to operate.
2 HMI
Multi-page reports, consisting of a display configured with a scroll DDO, can be printed (e.g. SQL data in tabular format). The Report does not print widget-based objects, e.g. buttons, pop-ups, etc. System lists and displays that use symbols or Sammi runtime key cannot be printed. The form is used to define the page layout, headers, font and size, and the general look of the report. The Send button prints a pre-configured report. The Write button saves the report definition. The New button allows a new report to be created. An existing report definition can be called up by entering the report name and pressing the Read button, the definition can then be modified and written back to disc. 2.14.5.1 Task/Report Scheduler
The Task/Report Scheduler allows the execution of periodic tasks to be scheduled. A task schedule can have multiple subtasks. Each subtask can be executed at a different frequency and start time. A subtask can be defined more than once with different frequencies and start times. The Task Schedule Definition Display is used to: Set up a new task. Read/write a task schedule. Insert/delete a subtask on the schedule. Turn on or off a subtask execution. Define the execution frequency, start time, maximum execution count, and SAMMI commands, for each subtask.
There are two types of task schedules: a system Report Schedule (identified by the file name report.sch) used by the system to produce periodic reports, and user definable task schedules (identified by file names prefixed with task_). Normally the Report Schedule is accessible by the operator whilst the other task schedules are only accessible by the configuration designer. Task schedules are per HMI Station; independent of other HMI Stations, i.e. backup task scheduling is not provided. If a periodic task is considered to be important, the same task should be scheduled to execute in more than one HMI Station in case of a station failure.
2.15
HMI Background Jobs
Each HMI console provides a background job list facility. Each job in the list consists of a trigger condition, and an action to perform when the trigger condition becomes true. The job is configured by typing into the display fields, and can be disabled/enabled by the buttons provided. This is a useful feature where actions are to be performed on a per HMI console rather than on a station/domain basis. Typical uses include: Close a digital control point (e.g. to initiate a remote audible alarm) when the HMI console audible alarm is turned on. Trip a digital control point (e.g. to cancel a remote audible alarm) when the HMI console audible alarm is turned off. Display a particular window when a point value exceeds some nominated value.
Up to 10 background jobs can be configured.
Page 77 of 215
2 HMI
The Trigger Condition is a Boolean expression similar to the aggregate read-key configuration (refer HMI Engineer's Manual for details) without the enclosing "(: and :)" characters. However, the expression must not contain symbols (e.g. {PTID}) nor SAMMI run-time keys (e.g. @ptid). The following special keywords are intended specifically for the HMI background job only. They are stand-alone and cannot be used in the aggregate read-key configuration. SOUND_ON triggers when the HMI console audible alarm is turned on. SOUND_OFF triggers when the HMI console audible alarm is turned off. EVERY_n triggers periodically, where n is an integer representing time in seconds.
The Action is either a SAMMI command (refer SAMMI Runtime Reference), or a HMI command (refer HMI Engineers Manual). There are two special commands TRIPCONTROL and CLOSECONTROL that are applicable for digital control points. These commands are intended specifically for the HMI background job only. The commands trigger a control procedure (i.e. reserve and execute). They do not produce any Event List messages. They abort silently if failure occurs (after all retries are used). If a job's flag is enabled, the HMI will check its trigger condition every second. Only when the trigger condition becomes true (i.e. the trigger state changes from false to true), will the action be queued for execution. Notes: The job is processed regardless of whether there is any user logon to SAMMI or not. Each job has its own action queue that can take up to 5 items. This is the total number of actions that have to be done. It is useful where an action is being executed and meanwhile the trigger conditions occur several times. The length of the queue is configurable. During software initialisation (i.e. when the HMI starts) or when a HMI background job is just enabled, no action will be taken even if the trigger condition is evaluated to true because the evaluation value is used as a reference. The one second period to check the trigger condition can be reduced to improve responsiveness (it is defined in a system startup file, on a per HMI console basis).
Page 78 of 215
3 FEP
FEP
The user defines the arrangement of RTUs and communications lines to RTUs. All available FEP stations perform the management of redundant FEPs, communications lines and RTUs synchronously.
HMI FEP/CS FEP/CS
LAN
CLS
CLS
RTU1 RTU2 RTU3
3.1
FEP Functionality Table

Protocol Conitel
The following table maps the FEP functions to protocols. Functionality DNP IEC Modbus ! !4 n/a ! n/a n/a n/a n/a n/a n/a n/a n/a n/a n/a
Line equipment: ! Terminal server ! ! ! CLS Dial-up line (Hayes) !4 C5 Protocol Converter n/a n/a C2020 ! Direct TCP/IP to RTU Scanning: ! ! Single point n/a ! ! Groups of points n/a ! ! Whole RTU n/a ! ! Time tagged status change !3 ! ! Time tagged analogue changes n/a ! Unsolicited messages n/a ! Non time tagged object changes n/a Other functions: ! RTU event limiting !2 n/a ! ! n/a Catchup Mode ! ! Time synchronisation !1 ! File transfer n/a Where: ! = Indicates combination is available. n/a = Indicates combination is not applicable. = Indicates combination is not supported. 1 = Supported on Communications Line Server (CLS) only. 2 = Built into protocol. 3 = In Conitel SOE messages only. 4 = Currently only available with terminal server. 5 = There is currently no support for any communication protocol listen mode.
Page 79 of 215
3 FEP
3.2
3.2.1
Communications Configurations
Serial Communications
Dual communications lines (Area A in diagram) with dual CLSs, line switching and dual FEP stations provide a secure configuration, with no single point of failure. There is no loss of communications for concurrent failure of any one communications line, with any one CLS, with any one LAN network, with any one FEP station. Both communications lines operate concurrently if necessary, as do both FEP stations and both CLSs. Line switches (Area A and C) allow the primary line to be used on the backup CLS if the primary CLS channel fails. Where backup communications lines are not available (Area C and D), FEP/CLS and LAN network failover still operates normally. Additional FEP stations and CLSs can be utilized to handle high communication loads, and for backup arrangements other than 1:1. A single FEP station, with all dual communications lines on a single CLS, can be utilized if backup at the master station is not considered necessary. Communications line failover still operates normally.
Primary FEP/CS1 FEP/CS2 Backup
LAN
CLS1
CLS2
CLS3
CLS4
RTU1 RTU4 Area A RTU2 RTU3 Area B RTU5 Area C
RTU6 RTU9 RTU7 RTU8 Area D RTU10
3.2.2
Direct TCP/IP to RTU
The RTU50 is available with two Ethernet interfaces that allow them to be directly connected to the LAN via TCP/IP. This is only available when using the DNP3 protocol. Additional equipment, such as routers, gateways, etc., may be used on the TCP/IP network between the FEP stations and RTUs. Dual TCP/IP communications links with dual FEP stations provide a secure configuration, with no single point of failure. There is no loss of communications for concurrent failure of any one communications link, with any one LAN network, with any one FEP station. Both communications links operate concurrently if necessary, as do both FEP stations.
Page 80 of 215
3 FEP
Primary FEP/CS1 FEP/CS2
Backup
LAN
LAN/WAN
TCP/IP communications links
RTU1 RTU2 RTU3
FEP makes a logical connection to each RTU port. There is no concept of line failure in this configuration, since all FEP communications with the RTU are via TCP/IP and there is no access to the physical lines. Configurations using direct TCP/IP to RTUs, have full failover/failback functionality, if the channel logical connection is configured to monitor availability of a previously failed logical connection. Additional FEP stations can be utilized to handle high communication loads, and for backup arrangements other than 1:1.
3.2.3
3.2.3.1
Line Equipment
Communications Line Servers (CLS)
A Communications Line Server (CLS) is the physical interface for FEP to the communications lines. It acts as a multiplexer/interface between the FEP and the communications interface cards connected to the field. The CLS directs requests from the FEP to the appropriate Dual Communications Board (DCB) in the CLS file, then sends the response if any back to the FEP. The CLS is communications packet oriented and supports various protocols including DNP3, IEC 60870-5-101 and Conitel. The CLS has a main CPU running Flash Card based firmware, supporting a dual 10BaseT TCP/IP Ethernet interface. The FEP makes a single logical connection to each CLS Ethernet port, which supports individual connections to each DCB channel on the CLS. A CLS has line switches on the field connections of all DCB interfaces (mounted on the communications line termination boards). A line switch switches the communications line between the same DCB and the same channel, on two CLSs. Each line switch is independent of all other switches on the same DCB and other DCBs, thus one CLS channel can fail over without failing the whole CLS. FEP controls the line switches. A CLS can contain up to 10 dual channel Electrobus II DCBs. The DCBs are responsible for the physical layer and part of the link layer of the communications interface. Each DCB is capable of simultaneous operation on both its communications channels. Various versions are available including models for ITU-T V.23 / BELL 202, ITU-T V.28 (RS232), and ITU-T V.11 (RS485). The DCB firmware determines which communications protocols can be supported by that DCB. A typical arrangement of two CLSs connected with line switching in a dual configuration is shown.
Page 81 of 215
3 FEP
LAN
CLS
CLS
CLS
DCB DCB DCB DCB total 1 2 3 4 of 14 ch ch 1 2
Dual Comms lines
CLSs can be employed with permanent line connections (i.e. no line switches). Here the backup communications line is typically connected to a different CLS, or at least a different DCB, as shown below.
LAN
CLS
CLS
Dual communication lines
Single communication lines
FEP can be configured to periodically send health check messages to the CLS. If no response is received within the configured timeout period, the test is considered failed. After the configured number of consecutive failures, the CLS is deemed to have failed and all channels on that CLS are failed. 3.2.3.2 Terminal Servers
A Terminal Server (TS) has multiple communications line channels (single channel). There are no line switches. It has a single TCP/IP Ethernet interface. A Terminal Server is byte oriented (e.g. it can handle DNP3, but for Conitel a protocol converter is required). A typical arrangement is shown. A Terminal Server can be used instead of a CLS. However, it has no line switches (Section 3.2.1 diagram - Area B and D) so the primary line cannot be used if the primary Terminal Server channel fails. FEP makes a logical connection to each Terminal Server serial port.
LAN
TS
TS
Dual comms line
Page 82 of 215
3 FEP
3.2.4
Communications Lines
Communications line types include a leased line, PABX or PSTN connection, ISDN, TCP/IP connection. 3.2.4.1 Dedicated Lines
Dedicated lines are those permanently available for communications. The FEP may send or accept messages from a number of RTUs over dedicated lines at any time. More than one dedicated line may be connected to the same RTU. FEP selects the line based on priority, which the user would configure based on performance and cost. If one line fails, communications can be switched to a redundant line.
Modems FEP
RTU1
RTU2
3.2.4.2
Dialup Lines
Dialup lines are specified on a channel basis. Each dialup line can connect to a single field modem (i.e. dialup modems cannot be switched). The communications line in the field can be used for a number of RTUs. The configured dialup information is used when a connection needs to be established. From then on, communications is the same as for a dedicated line. When the FEP has finished with the line, the connection is terminated (hung up). Dialup lines minimize communications costs when full time connections are not necessary (e.g. for backup lines).
Modem with auto dial facility FEP Telephone Network RTU1 RTU2 Modem in field
3.2.5
3.2.5.1
RTUs
Addressing
Each RTU on a communications line is assigned a unique station address. The same station address is used on the backup line. The RTU is normally configured so that accessing the RTU via either port achieves the same results (e.g. the same points are returned when scanning). A master station only communicates with one port at any given time. Another RTU port may be accessed at the same time by another system. For RTUs with direct TCP/IP connections, each RTU port also has a unique IP address.
Page 83 of 215
3 FEP
Line A
Line B
port 1 addr 21
RTU1
addr 21
port 2
Field Inputs/Outputs
3.2.5.2
Multiple Conitel RTUs with Same Station Address
For Conitel RTUs via a CLS, RTUs on the same communications line can have the same RTU station address, provided unique group addresses are assigned. This allows more RTUs to be connected to the same communications line. This feature has the following limitations on protocol support: Only C2025 compatible RTUs are allowed (feature not supported with C300). No time synchronisation support. No Remote Status Word retrieval by function code 9. No Sequence of Event support. Split RTU
3.2.5.3
A physical RTU can be logically split into two or more sections, and appear to the system as two or more separate RTUs. Each is treated as if it is separate hardware. This may be useful for large RTUs, or where field I/O is independent and is to be accessed from different stations concurrently. The field inputs and outputs assigned to one RTU (section) must not include any that are assigned to other RTU sections.
Line A Field Inputs/Outputs for RTU1 Line B
port 1 addr 21
RTU1
addr 21
port 2
port 3 addr 22
RTU2
addr 22
port 4
Field Inputs/Outputs for RTU2
3.3
Communications Management
The FEP provides communication management based on the status of FEP stations, communication hardware (line equipment), communications lines and available RTU ports. Where the configuration allows, FEP automatically initiates failover when communication failures occur, or when error rates become too high. Failover can also be manually initiated.
3.3.1
Communication Routes
FEP uses the concept of a route, which is the logical path between a FEP and RTU that is used to
3 FEP
communicate with the RTU. In the diagram, of a dual configuration, with line switching relays, eight routes are possible between the master station and RTU. The Database Configurator is used to define which of these routes should be used.
FEP1 FEP2 A route is the logical path between a FEP and a RTU. In this example 8 routes are possible, but not all would necessarily be configured. CLS1 Channel
1 2 21
LAN
CLS2
22
Routes via line A Routes via line B (Similar to line A)
RTU23 Line A Line B
The route concept minimizes the use of more expensive/slower backup communications lines, by only failing over a route rather than a whole line. It also provides a high degree of failover flexibility and the ability to share hardware. When a single RTU on a communications line fails to successfully communicate on the main route, the system uses a backup communications route (if available). Each route to a RTU is fully defined by specifying a FEP and channel. To configure a particular scheme, all desired routes to each RTU are configured. In a given system there may be multiple RTUs, multiple FEPs, and multiple channels. For each RTU the user configures one or more of the possible routes to that RTU, to achieve the desired level of redundancy, equipment/line usage and load sharing. Although a FEP can access any CLS channel, typically each FEP is assigned with a dedicated CLS, forming FEP/CLS pairs. By appropriate configuration of route priorities for different RTUs, the total communications load can be shared between several FEP/CLSs while they are healthy. If a FEP fails, then another takes over communications. Scan rates need to be chosen carefully to avoid overloading the remaining FEPs. The following table lists the normal case configured of four routes to a RTU, where either FEP/CLS pair connects to either communications line. Thus communications is normally via FEP1/CLS1 and the primary line. If FEP1 or CLS1 fails, the primary line is switched to CLS2. If the primary line fails, the backup line is used (on FEP1/CLS1). RTU Priority 23 1 23 2 23 3 23 4 FEP Channel SRM 1 1 1 2 21 1 1 2 4 2 22 4
Each route is assigned a priority number (1 is the highest). To avoid any confusion between the independent mechanisms of route failover/failback and channel failover/failback, it is recommended that the system be configured with higher priority routes associated with higher precedence channels. The channel uniquely defines the line equipment/DCB/channel/modem to be accessed. It also defines the line because only one line can be permanently connected, or be switched to that channel. The scan rate multiplier (SRM), range 1 to 10 (default value of 1), is used to slow the scanning down on backup routes (e.g. where the line is slower). The periodic scan interval is multiplied by the SRM.
Page 85 of 215
3 FEP
3.3.2
Failure Detection
A RTU may fail to respond correctly for many reasons including RTU failure, equipment/line failure, request timeout, message corruption, etc. There are three failure determination mechanisms: 1. Request timeout and retry. Communications to a RTU experiencing occasional errors, cause scan request retries. If errors get worse, the RTU may be put in the Scan Fail Mode, and subsequently recover when replies are received (Section 3.4.4). 2. Calculation of route and channel error rates. If route or channel error rates exceed a defined threshold value the communications on the route or channel is marked as failed. Typically, the error rate thresholds are configured so that failover does not occur immediately after a communication route goes into Scan Fail Mode. 3. Errors raised by an item of equipment or TCP/IP logical connection failure. A channel is marked failed when a hardware problem is detected. This is determined using several different mechanisms. FEP failure is also detected. Other FEPs can take over without a station restart. 3.3.2.1 Request Timeout and Retry
For each channel the user configures a request timeout period, and maximum number of retries. If FEP does not receive a reply within the request timeout period, or receives a bad message, it retries the scan request. The timeout is configurable between 1 and 65535 milli-seconds, typically 1 second. Scan requests are retried up to the maximum number configured. The maximum number of retries is between zero (for no retry) and 16. Typically this is set to 2 or 3, to avoid holding up the scanning of other RTUs on the same communications line, which cannot proceed while this request is in progress. For serial communications where the protocol supports a link layer (DNP3 and IEC 60870-5-101), a user configurable link layer request timeout period and maximum number of retries, is also supported. 3.3.2.2 Route Error Rate
The route error rate is calculated for each active route (includes retries). This is smoothed by a moving average equation, and expressed as a percentage of the total number of transactions. 0% indicates perfect communications (no errors), 100% indicates no successful communications (100% errors). The route error rate can be configured as a database point (refer Section 3.6). The route error rate is cleared whenever the route becomes active (i.e. when failover or failback occurs). The route failover threshold is configurable per route in the range 0 to 100%.
Route failover initiated here Shows case when there is no route to fail to
Transactions (%)
Route failover threshold Route error rate (smoothed)

Time
Route error rate (unsmoothed)
Moving Average Equation The moving average equation is: XT = ST + (1-)XT-1

3 FEP
Where: XT is the new moving average, calculated at the completion of a successful or failed transaction, is the reciprocal of the time constant, XT-1 is the previous value of the moving average, ST is the state of the just completed transaction (success=0 or fail=1). The value is configurable, in the range 0.0 to 1.0. If outside this range, a default value of 0.1 is used. The closer is to 1.0, the shorter the time constant (i.e. less importance placed on past transactions). 3.3.2.3 Channel Error Rate
A channel error rate is calculated for each active channel (includes its currently connected line). This is a weighted sum of all the route error rates on that channel, including the last used route error rate of routes that have failed over to another channel. The weighting factors (range 0 to 65535) are configurable for each RTU. The result is expressed as a percentage, 0% indicating perfect communications, 100% indicating no successful communications. The channel error rate can be configured as a database point (refer Section 3.6). The channel error rate is cleared whenever the channel becomes active (when failover/failback occurs). The channel fail threshold is configurable per channel in the range 0 to 100%. 3.3.2.4 Equipment/Connection Failure
If FEP detects that the line equipment, DCB, channel, or modem, etc has failed, it marks the channel as either Connection Failed or Initialization Failed. Between the FEP and line equipment are TCP/IP logical connections. Also RTUs directly connected by Ethernet have TCP/IP logical connections. If FEP detects that a section of the network is broken due to failure of a communications link or failure of an intermediate piece of network equipment, it marks the channel as Connection Failed. Channel connection can be configured for FEP to monitor availability of a previously failed logical connection.
3.3.3

Communications Failover/Failback
The system can be configured to have: Channel failover/failback only. Route failover/failback only. Channel and route failover/failback.
Channel failover/failback and route failover/failback are independent mechanisms.
3.3.4
Route Failover/Failback
Route failover selects an alternate route to communicate with a RTU, when that RTU fails to respond satisfactorily on the current route. For example, when one port of a RTU has failed or part of a communications line has failed, FEP may communicate with affected RTUs via another route, and not fail over the whole line. If no alternate route is available, FEP is forced to use the current route and continue to suffer communications errors. The scan mode is not changed. When the user manually restores a previously failed route or channel, or when FEP detects that a previously failed route is now available, this may or may not result in failback depending on current conditions. FEP resource management provides health monitoring of inactive device routes (that are available for scanning), by periodic checks at a configurable rate. When configured, it can detect when a previously failed higher priority route is now available, so that the route can be automatically restored. The health
3 FEP
monitoring of the lower priority routes ensures they can be used if the active route fails. 3.3.4.1 Automatic Fail/Restore
The primary determinant of route usage is the priority of the route. In a system that has not experienced any failures and has not been manipulated by the operator, a RTU will be have all data exchanged using the highest priority route. The route that is used for transferring data is called the active route (transferring data refers to all operations including health-checking, scanning, time synchronisation, controls, etc). The following information can effectively remove a route from the prioritised list of routes usable by a particular RTU for determining the active route: Channel communications state. A failure is indicated by the channel error rate exceeding the channel failover threshold, or connection failed, or initialisation failed. Route communications state. A failure is indicated by the route error rate exceeding the route failover threshold. Channel manual in/out of service state. Route manual in/out of service state.
The following rules apply when selecting an active route: Only one FEP controls a physical channel (and its currently connected line) at a time. Another FEP is not allowed to use the physical channel until failover/failback occurs. Only one FEP has an active route to a given RTU at any one time. Another FEP is not allowed to communicate with the RTU, via any communications line. A FEP is not allowed to change a line switch until failover/failback is necessary (i.e. there is no line switching back and forth during normal communications). Therefore, only the currently connected lines can be used. A previously failed channel is not available for use until it has been manually restored or the route health-checking feature has restored it. A previously failed route is not available for use until it has been manually restored or the route health-checking feature has restored it. Upon selection of a new route, the RTU is put into Recovery Mode (Section 3.4.4). The FEP aims for all RTUs to be in communication with the master station, and aims to obtain the best possible communications using available resources. Due to failures some routes may not be currently usable. This may result in selection of a lower priority route in preference to a higher priority route, or under some conditions an RTU may not be accessed at all. The following rules determine the interaction between channels and routes with respect to their communications states: Manual restoration of a channel restores all routes associated with that channel. Automatic restoration of a channel, by the error rate transitioning below the error threshold, does not affect the state of the routes associated with the channel. Automatic restoration of a channel, by restoration of a connection, does not affect the state of the routes associated with the channel. Restoration of one or more routes by any means (automatically by health check or by manual restoration) associated with a channel does not affect the state of the channel. A channel that only has a single route (either by configuration or by activity in failure modes) is considered failed if the single route is failed (since this is the only available information about the channel). When there is no communications on a channel, or the channel error rate exceeds the channel failover threshold, an event is generated. When there is no communications on a route, or the route error rate exceeds the route failover threshold, an event is generated.
Page 88 of 215
3 FEP
When the system is restarted, or a FEP station is restarted, or a failed FEP station is restored, etc, the highest priority route is always used as the active route, regardless of interim station status, order of stations coming online, etc. 3.3.4.2 Manual Fail/Restore
Failover is manually initiated by placing a component out of service. Manual restore is achieved by placing the component back into service. Restore may cause failback dependent on other current conditions. However, the system does not failback to a failed route or channel, even if the current route or channel is failed. Manual in/out of service can be performed on a FEP, channel, route and RTU. Manually initiated route failover operates similarly to automatic failover. However, if no backup route is available, communications to the RTU stops. Manually restoring a failed route does not restore any associated failed channel. Manually initiated channel failover operates similarly to automatic failover. However, if no backup channel is available, communications to the RTU stops. Manually restoring a failed channel restores its associated routes. To manually fail a line, the user manually fails all channels that can connect to that line. 3.3.4.3 Route Health Monitoring and Failback (Serial Communications)
A route may be configured to perform health checking and to automatically restore when the number of errors have subsided. This feature is called automatic route failback. If the health check request on a failed route provides successful responses, then the FEP will automatically failback to that route for that RTU if it is of higher priority, after the error rate has transitioned below half the configured error threshold. The rate of issuing of the health-check request is configurable. This feature is only useful for serial communications channels provided by the CLS or Terminal Server, because direct TCP/IP connections use other techniques to determine the health of the channel. The route health-checking mechanism has a linear back-off feature. If a route has failed, then the route is health-checked firstly at an initial rate and will then reduce over a defined period of time to a final rate. This is only useful in the case of multi-drop communications, where other RTUs on the same line use the line for retrieving data. By backing-off the rate of request sending, the communication line is freed for use for other RTUs. This feature is used during the time the route is in the failure state. Once a single successful reply is received, the route health-checking will resume operation at the initial scan rate. This ensures that recovery time is brief when short intermittent errors have occurred. Route health monitoring can only be performed on routes where their associated channel is available for scanning. The channel failure state determines whether a route is available for scanning (i.e. if it can establish a connection, has a line available for use, etc). Note that not all routes may be available for monitoring at once (e.g. where two or more routes from different FEP stations use the same channel, or for line switched configurations where two channels use the same communications line). Backup Routes Constant route health monitoring provides backup route health-checking functionality. All routes with health monitoring enabled, perform health checking when their associated channel is available for scanning.
3.3.5
Channel Failover/Failback
FEP uses the concept of a logical channel, which is the logical path between a FEP and physical channel (e.g. CLS DCB slot and channel). This is connected directly, or via line switching, to a communications line. Each logical channel is assigned a precedence number. In a system where multiple FEPs access the same (physical) communication line, channel precedence is used to determine which logical channel should be used. Channel precedence is not applicable where only one FEP accesses the communication line.
3 FEP
For channel precedence to have effect, the channel error thresholds must be configured greater than zero. Normally the channel error threshold is set higher than the associated route error thresholds. Channel failover selects an alternate logical channel when communications fail on the current communications line. If no alternate channel is available, FEP is forced to use the current channel and continue to suffer communications errors. The scan mode is not changed. The primary determinant of channel usage is the precedence of the channel. This is irrespective of the route priority associated with any of these channels. FEP follows these rules when selecting a logical channel: The logical channel must be available (i.e. not failed). Only one FEP controls a physical channel (and its currently connected line) at a time. Another FEP is not allowed to use the physical channel until failover/failback occurs. 3.3.5.1 Channel Health Monitoring and Failback (Direct TCP/IP Connections)
A channel with direct TCP/IP connection to RTU may be configured to perform health checking and to automatically restore when the number of errors have subsided. The rate of issuing of the health-check request is configurable. The health check message is implemented as an ICMP echo request (ping) and does not affect existing scanning connections. The channel is declared as connection failed if the number of request timeouts/errors exceed the error threshold.
3.4
Data Acquisition
Data from the RTU may be acquired via a scan request (periodic, continuous, demand or RTU initiated), or an RTU may send unsolicited messages. The field data is published to Core SCADA for processing and storing into the database. Control requests are initiated by the HMI, the Calculations subsystem and applications. They are passed to FEP via Core SCADA. Some other requests (e.g. time sync, health check) are also handled. All scan, control, etc, requests are serviced in priority order. For any particular channel, FEP only communicates with a single RTU at a time. Each scan request reply interchange is completed before the next request for that channel is started. Communications on other channels are not blocked.
3.4.1
3.4.1.1
Scan Requests
Periodic Scan Rate Requests
A periodic scan rate request is configured by a scan interval (range 1 to 65535 seconds), scan time offset (range of 0 to 65535 seconds), and priority (range 21 to 255, 21 being the highest). Optionally the scan requests can be synchronized to midnight. For example: a scan interval of 300 seconds with scan time offset of 3 seconds synchronized to midnight, is scheduled at 0000:03, 0005:03, 0010:03, 0015:03, etc. The scan at 0000:03 is synchronized to the real time clock. For scan times synchronized to midnight, FEP uses the real time clock for the time reference. If the real time clock is changed gradually by time synchronization the periodic scans remain synchronized. For scan times not synchronized to midnight, FEP schedules the first scan after FEP start-up, unrelated to the realtime clock. A separate scan interval is configured for the Active Scan Mode (normal operation), Scan Fail Mode, and Catchup Mode. Each can be configured as periodic, continuous, or none. A scan overrun occurs if FEP is unable to request a scheduled scan, before the next instance of the scan request is due. In this case the new scan is not scheduled. An analogue database point can be configured for each channel, route and RTU, in which the number of scan overruns last minute, is maintained (refer Section 3.6).
3 FEP
3.4.1.2
Continuous Scan Requests
Continuous scan requests, are configured by setting the scan interval for the Active Scan Mode to 0. They are assigned to the lowest priority. 3.4.1.3 Demand Scan Requests
Demand scan requests are initiated by the HMI, the Calculations subsystem and applications. They are passed to FEP via Core SCADA. FEP schedules a scan for the specified point or points, within the constraints of the communications protocol (note: this may cause other points to be scanned). For some protocols it is necessary to retrieve event information before the current (static) scan of the point can be retrieved. For DNP, when a change in state is expected (e.g. demand scan following a control), class 1, 2 and 3 (event) scans are issued if any periodic class 1, 2 or 3 (event) scans are configured. For operator or application initiated demand scans, the current state of the point is retrieved using whatever mechanism the RTU permits (which could be a single point or a set of points, depending on the RTUs DNP compliance level). Similarly the IEC 60870-5-101 protocol forces one or more class 1 requests before a single point is scanned such that events are retrieved. 3.4.1.4 RTU Initiated Scan Requests (IEC 60870-5-101, Conitel)
For IEC 60870-5-101, the RTU can indicate that events need collection, by setting a flag in the next message sent to the master station. If communications are in the Active Scan Mode, the FEP schedules scan requests to collect these events as soon as possible (it does not wait for the next periodic event scan). A periodic event scan is still useful, in case there are no other messages from the RTU, at that time. For Conitel, the RTU indicates that SOE events need collection, by setting a flag in the Remote Status Word (RSW) sent to the master station.
3.4.2
Unsolicited Messages
Unsolicited messages are where the RTU spontaneously emits a message containing point update information (e.g. report-by-exception). No scan request is involved. Unsolicited messages are only supported by some protocols. For protocols that support explicitly tagged data type information and/or configuration data uploads, the ISCADA system need not necessarily be installed with information describing the type and source of unsolicited data. However, if the system is to use any of the data, it requires configuration information to associate the data and its source in the field. Unsolicited messages from unknown RTUs are ignored.
3.4.3
Priority
All requests for a channel are serviced in priority order, 1 being the highest. Request types have the following priority: Priority Request type Priority Defined By 1-20 Control HMI, application 1-20 Demand scan HMI, application 2 Timesync (demand) Set by software 201 Timesync (periodic) Configured by user 21-255 Periodic scan Configured by user 1 40 RTU health check Configured by user 2552 File transfer Set by software 2552 Continuous scan Set by software Where: 1 = The recommended priority.
3 FEP
= File transfers and continuous scans on the same channel are interleaved.
3.4.4
3.4.4.1
Scan Modes
Normal scanning
Normal scanning is in the Active Scan Mode. Scan errors can cause a change to the scan mode, which is defined as follows: 1. Active Scan Mode - the RTUs scan replies are good. Scanning is at the active scan rates, with retries if any errors. 2. Scan Fail Mode - retries have failed to retrieve good replies. Recovery requests are at the scan fail rate, with no retries. 3. Recovery Mode a good scan reply is received. After time and data synchronization, scanning resumes. 4. Catchup Mode - if catchup is configured, the backlog of RTU events is collected, with optional Retrospective History processing, before returning to the Active Scan Mode. 3.4.4.2 Master Station and RTU Synchronisation
For DNP3 and IEC 60870-5-101 protocols, to ensure correct operation of the RTU event facility, the master station time and data must be in synchronisation with the RTU. For time synchronisation, the RTUs are set to the master station time (UTC) using the time synchronisation procedure of the protocol, which takes communications delays into account. Accuracy depends upon the latency characteristics of the communications medium (lower latency variation gives higher accuracy time synchronisation). The master station initiates time synchronisation with RTUs. For data synchronisation, all outstanding events are collected from the RTU, followed by the current value of all inputs. Synchronisation is performed: 1. When communications are restored. 2. When a RTU is put in scan, channel is put in service, route is put in service, or the RTU event buffer has overflowed causing RTU events to be lost. The RTU is put into Recovery Mode, except that it is assumed to be good, and therefore ignores the number of successful scans for recovery. 3. When the master station is restarted. The RTU is put into Scan Fail Mode and the RTU is shown with the initial state. 4. When the user configures a periodic confidence (static) scan to ensure data synchronisation with the RTU. 5. When the user configures periodic master station time synchronisation with the RTU. 3.4.4.3 Active Scan Mode
Scanning is at the active scan rates. RTU time synchronisation is performed according to the configured time synchronisation scan interval. For event scans, the number of events returned from the RTU is limited to avoid very large replies: For DNP3 event scans, the number of events is limited to the configured maximum number of events. If the number of events to be returned from the RTU exceeds the configured maximum number of events then the scan request is repeated, until all events are returned. Note that Catchup Mode is not entered (because this situation is simply a case of a short-term burst of events that need division into manageable size messages). For IEC 60870-5-101 event scans, the number of events is limited by the protocol. If the number of events to be returned from the RTU exceeds the limit, then scan requests are repeated, until all
Page 92 of 215
3 FEP
events are returned. Note that Catchup Mode is not entered. If a scan error occurs, the scan request is retried. If the specified maximum number of consecutive retries is exceeded, the reply (for data processing) is marked as scan fail, and the RTU is placed in Scan Fail Mode. The RTU Communications Lost quality flag is set. 3.4.4.4 Scan Fail Mode
Recovery requests are at the scan fail rate. For DNP3 and IEC 60870-5-101 protocols (i.e. those with a RTU event facility), the request is a simple type that expects a reply, but contains no data for processing. No retries are performed. When a good reply is received, the Recovery Mode is entered. Communications are not considered to have recovered until the number of consecutive successful scans reaches the configured number of successful scans for recovery (typically 2 or 3). The RTU Communications Lost quality flag is then reset. Until then, no retries are performed. Any failure causes a return to the Scan Fail Mode. 3.4.4.5 Recovery Mode
RTU time synchronisation is performed. Then if catchup is configured, the Catchup Mode is entered, otherwise the following is performed: DNP3 A combined scan (refer Section 3.5.1.1) is performed (regardless of whether events are configured or not), to ensure data synchronisation. Then the Active Scan Mode is entered. The master station and RTU communication link timeouts must be configured to allow for the maximum number of events, which may be returned, or preferably catchup is enabled. IEC 60870-5-101 An event scan is performed to collect all of the outstanding RTU events. Then a General Interrogation scan is performed to ensure data synchronisation. Then the Active Scan Mode is entered. Other Protocols No special action is taken. The Active Scan Mode is entered. 3.4.4.6 Catchup Mode (optional)
The aim of Catchup Mode is to provide a controlled method of collecting a backlog of RTU events before normal scanning resumes (e.g. after recovery from a communications failure). It is supported for DNP3 and IEC 60870-5-101 protocols, and enabled by configuration. Catchup should be enabled if RTU events are configured. In particular for DNP3, it avoids the possibility of a very large combined scan reply. Within catchup there are two options (also refer to Section 4.2.4): 1. Normal Catchup - Process the backlog of RTU events in the normal manner. Current RTU data (static scan) is not retrieved until all RTU events are retrieved. Configured by having no Catchup Mode class 0 scan rate. 2. Retrospective History, following recovery from a communications failure - Process the backlog of RTU events for event and history generation only. Current RTU data (static scan) is retrieved and processed normally to keep the system up to date. Configuring a Catchup Mode class 0 scan rate enables it. This option is not recommended (refer Section 4.2.4.1). DNP3 When Catchup Mode is entered, events are requested at the Catchup Mode scan rates (each scan limited to the maximum number of events). The Catchup Mode scan rates are usually configured to be slower than active scan rates. Configured static scans (class 0 and specific) are also performed. During Catchup Mode Controls are inhibited, because the point status is unknown, therefore the control action may not be consistent with the field.
3 FEP
When the backlog of RTU events has diminished, a combined scan (refer Section 3.5.1.1) is performed, to ensure data synchronisation. This is when the RTU has returned all original events, and any other events that have occurred since the Catchup Mode was entered. The RTU50 RTU implementation of buffered history retrieval guarantees that the data returned for a combined scan request is synchronized. The Active Scan Mode is then entered. IEC 60870-5-101 The same principle applies as for DNP3, except that the scan types are different (refer Section 3.5.2).
3.5
3.5.1
Communication Protocols
DNP3
DNP3, is an IEC 60870-5 compliant communications protocol (refer ISCADA Distributed Network Protocol Implementation). It is supported on workstation serial ports, terminal servers, the CLS V.28, V.23/Bell 202 and optical serial interfaces, and on TCP/IP Ethernet. Unsolicited messages are supported. The facilities described have been verified with the RTU50. Other RTUs may have some restrictions. 3.5.1.1 Types of Scan Request - A class 0 (static) scan obtains the current value of all objects configured in the RTU (not affected by master station configuration). Values are not time tagged in the RTU, the time stamp is placed on at the master station. - To avoid event timing issues, a class 0 scan request performs a combined scan (consisting of all event classes (1, 2, 3) that have been configured, followed by class 0), except when in Catchup Mode. - A class 1, 2 or 3 (event) scan obtains all changes of that set of points, since the last scan. Values are time tagged in the RTU (to 1 milli-second resolution, depending on time synchronisation). If no points have changed, the reply is empty. If a given point has changed several times, all changes are returned. RTU objects can be configured in class 1, 2, 3, or in no class (not affected by master station configuration). Typically: Specific points Class 1 - digitals. Class 2 - fast moving analogues. Class 3 - slow moving analogues (including accumulators). No class - points to be Individually scanned.
Class 0 scan
Combined scan
Class 1, 2 & 3 scan
- This (static) scan obtains the current value of individual points. Values are not time tagged in the RTU, the time stamp is placed on at the master station. Individual points are configured for scanning, in the master station (not affected by RTU configuration). The FEP attempts to group points in a minimum number of scan requests to reduce communications traffic.
Health check
- This is only used in the Scan Fail Mode. It is a simple request, to check for RTU communication recovery. The reply contains no data for processing.
3.5.1.2
Typical Scan Configuration
Normally event scanning (change notification), with an occasional static data confidence scan to ensure data synchronisation, is used. Typical scan rates and configuration is described in the Database Configurator Users Manual.
Page 94 of 215
3 FEP
Event scans (class 1, 2 and 3) are usually on a continuous scan (or high frequency rate), to access changes as they occur. Event scans are configured in synchronism with class 0 scans and of higher priority (this ensures that large quantities of events are collected prior to the combined scan). Static data scans (class 0) are usually on a low frequency rate (e.g. 15 minutes), a multiple of event scan rates.
3.5.2
IEC 60870-5 T101
IEC 60870-5-101, is an IEC 60870-5 compliant communications protocol (refer iSCADA System IEC 60870-5-101 Protocol Implementation). It is supported on the CLS V.28, V.23/Bell 202 and optical serial interfaces. The following features are not supported: Balanced Transmission. File transfer. Download of threshold value, low limit, etc to RTU. Support for protection equipment, step position. Reset process command. Broadcast event acquisition.
The facilities described have been verified with the RTU50. Other RTUs may have some restrictions. 3.5.2.1 Types of Scan Request
General interrogation - A general interrogation (static) scan obtains the current value of all objects configured in the RTU (not affected by master station configuration). Values are not time tagged in the RTU, the time stamp is placed on at the master station. Group interrogation - A group interrogation (static) scan obtains the current value of objects in the nominated group. RTU configured (not affected by master station configuration). Values are not time tagged in the RTU, the time stamp is placed on at the master station. RTU objects can be in one or more interrogation groups 1 to 16. Specific points - This (static) scan obtains the current value of individual points. Values are not time tagged in the RTU, the time stamp is placed on at the master station. Individual points are configured for scanning, in the master station (not affected by RTU configuration). Background scan - A background (static) scan obtains the current value of objects configured for background scanning. RTU configured (not affected by master station configuration). Values are not time tagged in the RTU, the time stamp is placed on at the master station. Background scanning is a low priority continuous scan that is interrupted whenever there is any other communication activities to perform. Event scan - An event scan obtains all changes of RTU inputs that trigger events, since the last scan. RTU configured (not affected by master station configuration). Values are time tagged in the RTU (to 1 milli-second resolution, depending on time synchronisation). If no points have changed, the reply is empty. If a given point has changed several times, all changes are returned. - This is only used in the Scan Fail Mode. It is a simple request, to check for the RTU communication recovery. The reply contains no data for processing.
Health check
Page 95 of 215
3 FEP
3.5.2.2
Typical Scan Configuration
Normally event scanning (change notification), with an occasional static data confidence scan to ensure data synchronisation, is used. Typical scan rates and configuration is described in the Database Configurator Users Manual. Event scans are usually on a continuous scan (or high frequency rate), to access changes as they occur. Event scans are configured in synchronism with general interrogation scans and of higher priority (this ensures that large quantities of events are collected prior to the general interrogation scan). Static data scans (general interrogation) are usually on a low frequency rate (e.g. 15 minutes), a multiple of event scan rates.
3.5.3
Conitel C2025 and C300 Protocol
Conitel, is an isochronous communications protocol (refer ISCADA Conitel C2025 Protocol specification, and Conitel C300 Protocol Specification). It is supported on the CLS V.28 and V.23/Bell 202 interfaces. Conitel C2020 (a subset of C2025) is also supported on workstation serial ports when used in conjunction with a C5 ASCII Serial to Conitel Converter. Conitel C2025 and C300 support SOE messages for one and two bit digital inputs, The SOE messages contain the new state of the digital input and a 1-millisecond resolution time stamp applied at the RTU. Other status changes have a 1-second resolution time stamp applied by FEP. For C2025 function Code 9, only group 5 (time update request), and group A (time correction factor establishment), are supported. The facilities described here have been verified with Conitel C2025 and C300 compatible RTUs (including the RTU50 RTU). 3.5.3.1 Types of Scan Request - A scan group request obtains the current value of objects in the nominated group. Values are not time tagged in the RTU, the time stamp is placed on at the master station. Each scan group can contain a mixture of digital and analogue points, with some restrictions, up to the maximum group size. The configuration is performed in the master station and RTU. The points and their order must agree. Conitel SOE - A SOE scan obtains all changes of that group of points, since the last scan. A SOE scan is only performed when there are SOE changes present, as indicated by the RTU during normal scanning. Values are time tagged in the RTU (to 1 milli-second resolution, depending on time synchronisation). If a given point has changed several times, all changes are returned. Conitel SOE facilitates one and two bit digital inputs (no MCDs or multi bit). Sets of digital points are configured into SOE scan groups, up to the maximum group size. The configuration is performed in the master station and RTU. The points and their order must agree. Health check - This reads the Remote Status Word (RSW) from the RTU, which contains RTU status information such as controls isolated, power supply low, SOE present, etc. There is no configuration needed (other than selecting a suitable scan rate). In Active Scan Mode, this status information is processed. In Scan Fail mode, this is used as a simple request to check for RTU communication recovery. The reply contains data, but it is not processed.
Scan group
Page 96 of 215
3 FEP
3.5.4
Modbus
The Modbus Protocol is specified in the Modicon Modbus Protocol Reference Guide. The RTU transmission mode is supported (refer ISCADA System Modbus Protocol Functional Specification). Supervisory control sequences are supported, including single pass (direct execute) controls, and two pass (check before execute) controls. The two-pass control mechanism is not standard Modbus, it requires the RTU to accept two sequential coil set commands and only action the output if both of these commands are correctly received, within a pre-set time. The facilities described here have been verified with a leading make of the PLC. 3.5.4.1 Types of Scan Request
The types of scan request available are: Specific points - This scan obtains the current value of individual points. Values are not time tagged in the RTU, the time stamp is placed on at the master station. Individual points are configured for scanning, in the master station (not affected by RTU configuration). Points can be scheduled at different scan rates. The FEP attempts to group points in a minimum number of scan requests to reduce communications traffic. Health check - This is only used in the Scan Fail Mode. It is a simple request, to check for RTU communication recovery. The reply contains no data for processing.
3.6
Communications Statistics and Status
FEP maintains status information and communications statistics for each configured channel, route, and RTU. This is displayed by the HMI (refer Section 2.13.3). The statistics are updated at a factory preset rate defined in a system startup file, default is 2 seconds. For Conitel, all scan groups scheduled in the same scan rate count as one request. For example, a 5 sec rate (12 per min) of 3 scan groups, and a 6 sec rate (10 per min) of 7 scan groups, gives 22 requests in the statistics (regardless of the number of actual scan groups). The error rate (% errors last minute calculated as a moving average, refer Section 3.3.2.2), and the number of scan overruns last minute, is stored in configured database points each minute. These database points can be configured to initiate an alarm if an acceptable value is exceeded. If digital points are configured with the same names as each channel, route, and RTU, the points are updated with the health of these objects. Each health point can be used to generate an alarm/event. The health point status is updated for both automatic failure detection and manual out of service. The point is set ON if any of the following are true: For a channel: The channel has failed due to exceeding its error threshold. The channel has failed because the connection has failed. The channel has failed because the channel hardware has failed to initialize.
For a route: The route has failed due to exceeding its error threshold.
For a RTU: Communications to the RTU has been lost. The RTU is reporting that it has some kind of trouble. No messages have been sent to the RTU for a period of time that is a multiple of the expected longest time between requests. This indicates that FEP has encountered an internal error. This multiple is fixed at 5.
3.7
RTU File Transfer API (DNP3)

Page 97 of 215
FEP provides file transfer facilities, for utilities to function over the RTU communications link.
3 FEP
Currently this is only available for the DNP3 protocol. The RTU file transfer facilities are available for use by application programs, as a set of functions in the Remote DAPI (RDAPI) form (refer Section 12.1). This is a C++ language interface. The following file transfer functions are provided: Connect to a RTU. Disconnect from a RTU. Write a file. Append to a file (only applicable to true files, ignored otherwise). Delete a file (only applicable to true files, ignored otherwise). Read a file.
These functions utilize the standard DNP3 file transfer sub-protocol. The protocol for using the file transfer functions includes a RTU connection protocol, by which a given application reserves a connection with a destination RTU. Other applications wishing to communicate with that RTU are locked out for the duration of the session. File transfer requests have a lower priority than most scan requests (the priority is fixed in software). When a file is being transferred, it does not hold up the channel, because other requests (e.g. controls, scan requests) of a higher priority are transmitted in between the file fragments. All files are treated as 8 bit binary type. The file structure is of type stream of bytes, as in the UNIX file system. Record delimited operations are not executed, the start record must be 0, and the end record must be 65535, in accordance with the DNP3 protocol to address a whole file.
Page 98 of 215
4 Core SCADA
CORE SCADA
Core SCADA processes raw data from FEP, and data from applications, calculations, and manual entry, and then updates iSCADA objects (primarily analogue, digital and accumulator database points), it also processes digital and analogue controls and administrative actions from the HMI Station, application programs, etc. These can be telemetered, calculated, manual or telemetered controllable. Attributes include the point name, point classifications (e.g. area, category), current value/status, 64-bit quality flags (to indicate software detected and manually entered point conditions), alarm limits, and scan/control information. When a database point value is updated, a time tag is stored in the point. The time tag is used in any alarm, event, off-normal and history generation. Time tags generated by the master station have a 1 second resolution. For RTUs and communication protocols that support time tagging of data changes, time tags typically have a 1 milli-second resolution. Any old buffered data received from an RTU is processed as normal (e.g. after communications recovery). Optionally, for DNP and IEC101, a feature known as retrospective history can be used after communications recovery. Retrospective history processing provides a method of keeping the system up to date with current field data, while a large amount of old data is collected from a RTU. The old data is only used to generate events and for history storage. Conitel RTUs support Conitel Sequence of Events (Conitel SOE) messages. These messages are formatted into events (using the Conitel SOE time stamp) and entered in the Event List. The Conitel SOE message is not used to update the status of the digital point.
4.1
Core SCADA Functionality Table

Protocol IEC101 Conitel ! ! ! n/a n/a n/a ! n/a n/a n/a n/a ! ! ! ! ! n/a ! n/a n/a ! ! ! ! ! ! ! n/a n/a ! ! !1 !1 ! ! ! ! n/a n/a n/a n/a n/a
The following table maps the Core SCADA functions to protocols. Input/Processing Type DNP Analogue: Linear BCD1 to 6 Digital: One bit Two bit Multi bit - BCD1 to 2 MCD single contact MCD double contact Accumulator: 16 bit 32 bit 12 bit 24 bit Conitel SOE: One bit Two bit Controls: Digital Analogue raise/lower Analogue setpoint Two pass control Quality flags: Device Overrange Device Reference Error Device Offline Device Comms Lost Device Restart
Modbus ! ! ! ! ! n/a n/a ! n/a ! ! n/a n/a n/a n/a n/a

Page 99 of 215
! ! ! n/a n/a ! ! n/a n/a n/a n/a ! ! ! ! ! ! ! ! !
4 Core SCADA
! ! Device Forced Data ! Device Chatter n/a ! Device Invalid n/a Other functions: ! ! Retrospective history Where: ! = Indicates combination is available. n/a = Indicates combination is not applicable. = Indicates combination is not currently supported. 1 = Currently via a Communications Line Server (CLS) only.
n/a n/a n/a n/a
n/a n/a n/a n/a
4.2
Data Processing
Messages received by Core SCADA from the FEP are processed to extract data to update point attributes. All data in the message is time tagged. The point defines what data processing is performed. Typical processing is: Analogue Point: ADC limit and Engineering limit checking Linear conversion Input filtering Storage of RTU floating point values Storage of calculated and manual points Digital Point: One or two bit status inputs Storage of calculated and manual points Accumulator Point: Accumulator processing In addition for the Conitel Protocol: BCD inputs Single or double contact Momentary Change Detection (MCD) inputs Conitel SOEs processing
4.2.1
Analogue Points
There are three types of analogue points: telemetered, calculated and manual. The database point supports single precision floating point values. A telemetered analogue value can be either a raw ADC value (unipolar or bipolar), or an engineering value, configured on a per point basis. 4.2.1.1 Telemetered Analogue Points - Raw ADC Value Input
A raw ADC value is first checked against the minimum and maximum ADC count. If it is outside the valid range it is rejected, the points current engineering value is unchanged but is flagged under range or over range accordingly. An operator action event is generated. When the ADC value returns to the valid range, the under/over range quality flag is cleared, and a return from bad event is generated. The under range and over range checks can be individually disabled at configuration time.
Page 100 of 215
4 Core SCADA
Eng value is not allowed to exceed Eng Max
Engineering Value Eng value is unchanged for sudden overrange swing
Bad
Over Range Engineering Maximum Alarm Zones Engineering conversion Eng Min ADC Minimum ADC Maximum ADC Deadband ADC Counts
Good
Normal Zone Alarm Zones
Bad
Under Range
ADC Deadband
point goes bad no effect on point
Bad causes: Point quality = input bad Event for bad condition Alarm state change to bad Good causes: Point quality = not bad Event for return from bad Alarm state change from bad
no effect on point
point goes good Transducer fails
Under-range
Field device signal range
Over-range
A deadband value may be configured on a per point basis, as a number of ADC counts. In the situation where an analogue input hovers around an ADC limit, this deadband can limit excessive out of range events being generated. If the raw value is valid, it is converted into an engineering value using the input conversion method and the parameters defined for the point. With a deadband, the raw value is not converted into an engineering value, until it exits the deadband. The converted value is checked that it is within the engineering range, else the points current engineering value is unchanged but is flagged under range or over range accordingly. If the value is valid, it is stored in the database. Linear Conversion Function: y = Ax + B Where: y is resultant engineering value. x is ADC count. A is the conversion slope and B is the conversion offset. The user configures the engineering minimum & maximum values, and the ADC minimum & maximum counts, then the Configurator calculates the correct A and B constants. Both A and B can be positive or negative. Negative A means the conversion slope is negative. That is, when the ADC minimum value is set greater than the ADC maximum value. BCD Conversion (Conitel Only) BCD inputs in the form of four-bit values are converted into an engineering value. From 1 to 6 four-bit input values, each representing 0 to 9 are handled. The user configures the BCD input type BCD1, BCD1.5, BCD2, BCD3, BCD4, BCD5 or BCD6. The resultant values for types BCD1 to 6 are 0 to 9, 0
Page 101 of 215
4 Core SCADA
to 99, 0 to 999, 0 to 9999, 0 to 99999, 0 to 999999 respectively. BCD1.5 ranges from 0 to 19. If any BCD digit is outside of the valid range, then a conversion error is flagged and the value is not updated. 4.2.1.2 Telemetered Analogue Points - Engineering Value Input
For an engineering value input, if the value to be stored is outside the engineering range it is rejected, and the point is flagged under range or over range accordingly. An operator action event is also generated. If the value is valid, it is stored in the database. The under range and over range checks can be individually disabled at configuration time. 4.2.1.3 Telemetered Analogue Points - Low Cut/Zero Snap Functions
Low Cut provides for suppression of transducer fluctuations about the engineering minimum (typically) (e.g. zero). This allows noise to be cut from the value around the low span mark so that logic based on flow/no flow works correctly for small inaccuracies in transducers. A telemetered analogue point has a value ranging from the engineering minimum to the engineering maximum. The low cut value is defined in engineering units and applied at the bottom of the engineering range to give a low cut region. The region is the engineering minimum low cut value (including the boundaries). If the engineering value falls in the low cut region, then the value is set to the engineering minimum. If the engineering value falls below the low cut region, then the value is processed as for under range. The under range check can be disabled, this does not affect low cut. The ADC deadband (if any) does not affect low cut.
Eng Value
Input Eng value Eng value goes below low cut region into under range, so value is set Bad Result Eng value B
Low Cut Region B G
Eng Minimum
Under Range
Eng value set to Eng Minimum while in Low Cut region
Alternatively, to allow for inverted engineering unit conversion slopes, Low Cut can be applied to the high end of the engineering range. In this case, the region is the engineering maximum low cut value. If the engineering value falls in the low cut region, then it is set to the engineering maximum. Alternatively, where the engineering range is not bounded by zero, the Zero Snap option allows the low cut region to be positioned around the zero mark. The region is zero low cut value. If the engineering value falls in the low cut region, then the value is set to zero.
Page 102 of 215
4 Core SCADA
Eng Value
Input Eng value Result Eng value
Zero Snap
Low Cut Region
Eng value set to zero while in Low Cut region
Because Low Cut works on the engineering value, the Low Cut function is independent of whether the input is in ADC counts or engineering value. Bipolar analogue inputs are allowed. Low Cut is configurable on a per point basis. It is expressed in absolute engineering units. A value of zero (the default) indicates no low cut. The user can only configure a low cut value that is less than the engineering range. If the telemetered analogue point has manual override or point substitution, Low Cut is not applied to the value. Thus if the value is in the low cut region, the analogue point retains that value. 4.2.1.4 Telemetered Analogue - Manual Override
If a telemetered analogue (or digital) point is in manual override, then: Any manually entered value is processed as for manual points. Manual override also overrides point substitution. The bad data quality flags (e.g. point out of scan, scan error, input bad, etc) are not cleared but are overridden by software that accesses the point, when necessary (e.g. when testing if a point is bad). The bad data quality flags continue to be updated by the normal scan of field data. This enables applications to determine whether the actual telemetered input is good or bad. When manual override is removed: If point substitution is ON, the point is updated from the receiving point. Otherwise, the point is demand scanned, to bring it up to date with the field value. The bad data quality flags will already be up to date. 4.2.1.5 Telemetered Analogue - Point Substitution
If a telemetered analogue (or digital) point has point substitution ON, then: Any substituted value is processed and used as normal (e.g. alarm/event generation, displays, calculations, history storage, etc). The receiving point is updated from the source point whenever the source points condition changes. The highest precedence copy of the source point that is available is accessed. If the source point is Bad or not accessible, then the receiving points substitute point bad quality flag is set, and the value is not changed. Only the value is copied from the source point to the receiving point (i.e. no quality flags, update time, etc). If the value to be stored is outside the analogue engineering range or the digital defined state range it is rejected, and the receiving points substitute point bad quality flag is set. An operator action event is also generated. (Future) The bad data quality flags (e.g. point out of scan, scan error, input bad, etc) are not cleared but are overridden by software that accesses the point, when necessary (e.g. when testing if a point is bad).
Page 103 of 215
4 Core SCADA
The receiving points bad data quality flags continue to be updated by the normal scan of field data. This enables applications to determine whether the actual telemetered input is good or bad. When point substitution is removed: If the point is in manual override, its value is unchanged (i.e. becomes the new manual value). Otherwise, the point is demand scanned, to bring it up to date with the field value. The bad data quality flags will already be up to date. 4.2.1.6 Calculated Analogue Points
If the value to be stored is outside the engineering range it is rejected, and the point is flagged under range or over range accordingly. An operator action event is also generated. The under range and over range checks can be individually disabled at configuration time. Manual Override If a calculated analogue (or digital) point is in manual override, then: Any manually entered value is processed as for manual points. The bad data quality flags (e.g. point out of scan, scan error, input bad, etc) are not cleared but are overridden by software that accesses the point, when necessary (e.g. when testing if a point is bad). The bad data quality flags continue to be updated by the normal processing of the calculated result. When manual override is removed, the point is updated with the next calculated result. The bad data quality flags will already be up to date. 4.2.1.7 Manual Analogue Points
If the value to be stored is outside the engineering range, the update request is rejected. The under range and over range checks can be individually disabled at configuration time. 4.2.1.8 Analogue Input Filtering
A filter may be configured for telemetered and calculated analogue values. It is applied as part of the analogue conversion process after transducer checks, but before limit processing on the current value. A manually entered or point substituted value does not have the filter applied. This avoids contradicting the operators entry. The filter function is: Output value = F/100 * new telemetered value + (1-F)/100 * old point value Where: F is the filter constant in the range 0 to 100%.
4.2.2
Digital Points
There are three types of digital points: telemetered, calculated and manual. 8 bits are used to represent up to 256 possible states. Two states are used for a one-bit input, four states for a two-bit input, and up to 256 states for a multi-bit input. For telemetered points, the input processing converts the raw data to standard binary representation. 4.2.2.1 Telemetered Digital Points - One Bit Status Inputs
One-Bit Status Inputs are used for monitoring single contact indications. The default relationship is a closed contact represents the A state condition and an open contact indicates the B state. The A and B states do not refer to a and b contact types.
Page 104 of 215
4 Core SCADA
Database State B (=2) Close (ON, 1) Contact closed when point in A state. A (=1) Current Value Attribute (State Text selector)
Open (OFF, 0)
The input may be inverted by a contact inversion function (configured using the Database Configurator). The A state normally corresponds to the active field state. Physical interpretations may include ON, IN SERVICE, AUTOMATIC, CLOSED, INHIBITED, etc. The B state normally corresponds to the non-active field state. Physical interpretations may include OFF, OUT OF SERVICE, MANUAL, OPEN, ENABLED, etc. The terms A state and B state are used to make reference to the two database states, in the Database Configurator. Associated with the two states are sets of state text, e.g. OPEN, CLOSED, IN SERVICE, OUT OF SERVICE, etc. These are configured on a system wide basis and assigned to specific points using the Database Configurator. Either the A or B state can be defined as the normal state, for the generation of the Off-Normal List. 4.2.2.2 Telemetered Digital Points - Two Bit Status Inputs
Two Bit Status Inputs are used for monitoring double contact indications, including circuit breaker status and valve position. For such inputs, the A and B contacts are mapped to four states: 0, A, B and AB. The A and B states are regarded as the most common states of the point. Inputs may be inverted by a contact inversion function (configured using the Database Configurator). Associated with the four states are sets of state texts e.g. INDET, OPEN, CLOSED, and INVALID. These are configured on a system wide basis and assigned to specific points using the Database Configurator. Either the A or B state can be defined as the normal state, for the generation of the Off-Normal List.
Database State B (=2) Close A Contact Open A contact closed when point in A or AB state. A (=1) 0 (=0) AB (=3) Current Value Attribute (State Text selector)
Close B Contact Open B contact closed when point in B or AB state.
4.2.2.3
Telemetered Digital Points - Multi Bit Status Inputs (Conitel Only)
A multi-bit input is first checked against the defined state range (minimum of 0 to a maximum of 255). If it is outside the valid range it is rejected, and the point is flagged under range or over range
4 Core SCADA
accordingly. An operator action event is also generated. When the input returns to the valid range, the under/over range quality flag is cleared, and a return from bad event is generated. The under range and over range checks cannot be disabled. If the input is valid, it is converted into a digital state (integer) using the input conversion method defined for the point, and stored in the database. Associated with the multi-states are sets of (up to 256) state text. These are configured on a system wide basis and assigned to specific points using the Database Configurator. 4.2.2.4 Telemetered Digital Points - BCD Conversion (Conitel Only)
BCD inputs in the form of four-bit values are converted into a digital state. From 1 to 2 four-bit input values, each representing 0 to 9 are handled. The user configures the BCD input type BCD1, BCD1.5, BCD2. The resultant values for types BCD1 to 2 are 0 to 9, 0 to 99 respectively. BCD1.5 ranges from 0 to 19. If any BCD digit is outside of the valid range, a conversion error is flagged and the value is not updated. 4.2.2.5 Telemetered Digital Points - Single Contact MCD (Conitel Only)
The Conitel protocol supports the reporting of fleeting contact changes that have been detected between periodic scans. This is called Momentary Change Detection (MCD), which is available for single and double contacts. For each single contact MCD input, two data bits are transmitted by the RTU. The first bit, the MCD bit, indicates that a momentary change has occurred. The second bit indicates the input current status. For some RTUs the order of the MCD bit and the status bit may be reversed. The software corrects the data bit ordering, if specified in the Configurator. The detected changes are recorded with the same scan time, and processed identically to single status inputs. Thus point processing occurs for each of the state changes (e.g. events are generated for each new state). Three separate MCD types are supported: MCD A: MCD bit set on input transitions from open to close. The status bit is set on an open contact. This type allows up to 2 transitions to be detected always, and 3 transitions to be detected from a starting state of closed. MCD B: MCD bit set on input transitions from closed to open. The status bit is set on a closed contact. This type allows up to 2 transitions to be detected always, and 3 transitions to be detected from a starting state of open. MCD C: MCD bit set on input transitions from open to closed or from closed to open. The status bit is set on a closed contact. This type allows up to 3 transitions to be detected always. The status input may be inverted by a contact inversion function (configured using the Database Configurator). The contact inversion has the effect of changing a MCD A type to a MCD B type, and vice versa. The MCD C type is unaffected. 4.2.2.6 Telemetered Digital Points - Double Contact MCD (Conitel Only)
Double contact MCDs are processed as two single contact MCDs. They return 4 bits of data from the RTU comprising two status bits and two MCD bits. The ordering of status and MCD bits and contact inversion is supported as for one-bit status inputs. Three separate MCD types are supported, as for one-bit MCDs. 4.2.2.7 Telemetered Digital - Manual Override
Refer to Telemetered Analogue - Manual Override, Section 4.2.1.4.
Page 106 of 215
4 Core SCADA
4.2.2.8
Telemetered Digital - Point Substitution
Refer to Telemetered Analogue - Point Substitution, Section 4.2.1.5. 4.2.2.9 Calculated Digital Points
Calculated digital points support up to 256 states. The point values are in the range 0 to 255. The value is rejected if it is outside this range, and it is flagged under range or over range accordingly. An operator action event is also generated. The under range and over range checks cannot be disabled. For manual override refer to Calculated Analogue Points, Section 4.2.1.5. 4.2.2.10 Manual Digital Points
Manual digital points support between 1 and 256 states. The point values are in the range 0 to 255. The value is rejected if it is outside this range. The under range and over range checks cannot be disabled.
4.2.3
Accumulator Points
Accumulator points are used to support RTU counters which count pulses from pulse transmitters (e.g. meters). For all protocols, the static and event replies must be configured to return the raw count of the RTU counter (not the delta), with time. 4.2.3.1 Master Station Accumulator Point Types
There are two types of accumulator point used: 1. A Telemetered Accumulator Point (TAP) is used to store the instantaneous accumulator data (delta raw count, or delta change in engineering units), resulting from periodic scans of the RTU counter. 2. A Calculated Accumulator Point (CAP) is used to store the accumulated value for the configured period (e.g. hour accumulation of MWatt, 1-day accumulation of gas flow). Current value (i.e. point value reset at end of period) and completed value (i.e. point retains value for whole of next period) types are supported.
RTU
Raw Count Pulse Transmitter scan
MASTER STATION
Telemetered Accumulator Point (TAP) Delta Raw Count, or Delta Engineering Value each scan Hour CAP Current or Completed Value Type
1 Hour CAP
Current or Completed Value Type
1 Day CAP
Current or Completed Value Type
Continuous CAP
Current Value Type only
4.2.3.2 Conitel
RTU Counter Support
In the Conitel protocol, only values of frozen counters (which it calls Accumulators) are reported. The RTU counters are scanned with a Freeze and Scan command. The counter value is only frozen when the master station command is received. Thus the exact freeze time varies depending on master station and communications loading. Periodic scan
Page 107 of 215
4 Core SCADA
requests do not occur exactly on the intended period, and do not give precise accumulations for the intended period. The master station does not support broadcast freeze. RTU counter size: 12 or 24 bits.
CAP accumulations for a given period, singularly and system wide, have limited accuracy (in terms of accumulation period timing). However, the CAP is usually perfectly adequate for revenue metering. More accurate results may be obtained by writing an application program to calculate the accumulations for the intended period, using the TAP value/timestamp pair, and interpolating to the period start/end. DNP3 In the DNP3 protocol, running and frozen RTU counters are supported. Running counters are normally used unless more accuracy (in terms of accumulation period timing) is needed. Frozen counters are very good for revenue metering because they allow for an integrated total over a given period. Counters can only be frozen locally by the RTU, the master does not issue any freeze commands. Where frozen counters are used, the RTU performs automatic freezes at the required time intervals and reports those frozen counter values. The master station does not support broadcast freeze. RTU counter size: 32 bits, but the RTU can be configured to only report the bottom 16-bits. The master must be configured with the rollover point of the reported size for each value so that it can identify a 16-bit rollover or a 32-bit rollover. CAP accumulations of frozen counters for a given period, singularly and system wide, can have good accuracy (in terms of accumulation period timing). IEC101 In the IEC101 protocol, only values of frozen counters (which it calls Integrated Totals) are reported. The RTU counters can be frozen by the RTU or by the master station. The protocol specification outlines four methods for returning counter data, called Modes A, B, C and D. For accuracy (in terms of accumulation period timing), local RTU freezing of counters should be used. This is more accurate than using a freeze command sent by the master station. Mode A: Local freeze with spontaneous transmission. An application in the RTU issues a freeze locally (e.g. periodically), and the frozen value is sent to the master station as a change event. The master does not issue any commands to freeze or explicitly read the counters. The change events can be time tagged. Mode A also provides for the buffering of change events from a series of consecutive accumulation periods to be reported upon restoration of communications after an outage. Mode B: Local freeze with counter interrogation. A local process periodically freezes the counter values (as in Mode A), but no change event is reported. The master must explicitly read the frozen counter value, and must do so at least once in each freeze period in order to avoid loosing data. With master station freezing, the exact freeze time varies depending on master station and communications loading. Thus periodic freeze commands do not occur exactly on the intended period, and may not give precise accumulations for the intended period. Mode C: Master freeze with counter interrogation. A master station command is issued to freeze the counters (as in Mode D), but no change event is reported. A separate master station command is issued to explicitly read the frozen counter value. Mode D: Master freeze with spontaneous transmission. The master station issues a command to freeze the counters, and the frozen value is sent to the master station as a change event. The master does not issue a command to read the counter. The change events can be time tagged. The master station does not support broadcast freeze. RTU counter size: 32 bits.
With local RTU freezing of counters, CAP accumulations for a given period, singularly and system
4 Core SCADA
wide, can have good accuracy (in terms of accumulation period timing). Modbus The Modbus protocol does not support RTU counters. 4.2.3.3 Telemetered Accumulator Point (TAP)
RTU counters are normally scanned periodically. The scan period must be configured such that at least two scans would be performed in the time it takes the RTU counter to wrap around (i.e. it has rolled over and gone past the same value). The previous raw count is subtracted from the new raw count to form a delta raw count. This calculation takes into account RTU accumulator rollover, by using the rollover value configured in the point. The rollover value must be configured to the highest RTU accumulator value returned by the protocol, with the next value being 0. For a DNP3 32 bit accumulator configured to return only the least significant 16 bits, the rollover value must be for 16 bits. For the following error conditions, the new raw count is not processed, the point is flagged Input Bad, and an error is logged: If the new raw count is higher than the rollover value. If the new raw count appears to have moved backwards. This is indicated by a very large delta raw count (i.e. greater than half the configured rollover value) that is not preceded by a scan failure. This could occur if the data reported from field is out of time sequence. Note that processing is carried out by TAP in the sequence in which it gets data reported from field. The time stamp is not used to ignore the values.
For accumulators with flutter at the low end, or their true zero being greater than zero count, a number of pulses per minute that represent zero can be specified. The time difference from the last scan is used to proportion the per-minute value, which is then subtracted from the delta raw count to give an adjusted delta raw count. If the adjusted delta raw count is negative then it is zeroed. The default number of pulses per minute that represent zero is zero to process all data received. If the time ever goes backwards, subtraction is not performed. The adjusted delta raw count is then multiplied by the configured number of engineering units represented by one pulse (one raw count), to give the delta engineering value. The TAP can be configured to store (e.g. for display), the delta between successive raw counts from the RTU, as either: The delta raw count (not adjusted delta raw count). Note the TAP current value attribute is a floating-point type with 6 digits in precision. Or, the delta engineering value. This option is the default.
A TAP does not have under/over range checks. The following should be noted when using TAPs. For these reasons, it is recommended that a CAP be used instead. 1. Intervals between TAP updates may not be regular, thus the TAP delta value may fluctuate for a constant RTU pulse input. It is even possible to observe some delta values of zero. Therefore the TAP value must be interpreted as a value and timestamp pair. Irregular TAP updates occur as follows: For Conitel, the raw count is received in a scan reply, resulting from a periodic scan. During normal scanning conditions, this produces replies with only small fluctuations from the regular period (i.e. due to communications delays, CPU loading, etc). For DNP3, the raw count is received in a scan reply, normally resulting from a periodic event scan. This produces replies with only small fluctuations from the regular period (i.e. due to communications delays, CPU loading, etc), except that when a class 0 scan occurs (causing a combined scan) two scan replies may be received causing the TAP delta value to be small or zero.
Page 109 of 215
4 Core SCADA
Upon abnormal conditions such as RTU event buffer full, communications recovery, RTU restart, master station restart, etc., several scan replies may be received causing the TAP delta value to be small or zero. Optionally, the RTU counter can be configured not to generate events. Then the operation would be more similar to Conitel protocol (i.e. more regular updates). For IEC101, operation is similar to DNP3.
2. When using RTU event scanning (e.g. usually with DNP3, IEC101), and the RTU counter is not changing, the TAP delta value is not zero like it should be, until a static scan occurs. This is because only changes are received (i.e. there is no RTU event when the raw count is not changing). 4.2.3.4 Calculated Accumulator Point (CAP) Current Value Type
A current value CAP contains the current accumulated value (in engineering units) over a time period. It accumulates the delta value of TAP whenever the TAP is updated. Any number of CAPs could be associated with one TAP. The accumulation period is configurable on a per point basis. The accumulation period is synchronized with realtime. For accumulation periods equal to or greater than 1 hour, the accumulation period is relative to a logical start time of day, configured in the database by a system constant. Typical accumulation periods are: Minutes: 1, 5, 10, 15, 30 Hours: 1, 8 Days: 1 Continuous
It is recommended that the period be set to a multiple of the scan rate, preferably several times the scan rate so that the result is based on sufficient samples (e.g. a 1-minute accumulation period employing a 5-second TAP scan rate). The user should also consider configuring an offset for the TAP scan rate. This avoids the TAP receiving a scan reply close to the CAP period end, and not knowing which CAP period the scan reply is included in. CAPs work on local time. For accumulation periods greater than 1 hour, if the local time changes (e.g. daylight saving time changes), then accumulations are affected. If the time change is forward by say 1 hour, then a daily accumulation will have 23 hours, and an 8 hourly will have 7 hours. If the time change is backward by say 1 hour, then a daily accumulation will have 25 hours, and an 8 hourly will have 9 hours. The accumulated value and quality flags are reset at the end of the accumulation period. The RTU data from a scan at the end of period (containing data up to the end of period) will most likely be accumulated into the following period. The example below shows a 5-minute scan rate and 1-hour accumulation period. Where is important to display/collect the accumulated value at the end of the period, a completed value CAP should be used.
09:00 end of period Reset at 9:00 09:00 scan reply occurs and is processed a little after 09:00. It is included in next period
Scan occurs just after scheduled time
08:55
09:00
09:05
09:10
09:15
09:20
A continuous accumulation period provides accumulation over any period. There is no software reset. A CAP can be manually reset (e.g. by an operator via a display).
4 Core SCADA
A CAP does not have under/over range checks, or manual override facility. Accuracy (Current and Completed Value CAPs) For both current and completed value CAPs, the accuracy (in terms of periodicity) is limited by the following. There is no interpolation to the period start/end. The RTU data from a scan at the end of period (containing data up to the end of period) will most likely be accumulated into the following period. Exactly when the RTU counter is frozen/scanned at the period boundary. When TAP updates near the period boundary actually occur. Calculated Accumulator Point (CAP) Completed Value Type
4.2.3.5
If the completed value option is configured, the point retains the previous period accumulation value, for the whole of the current period. Accumulation for the current period is internal to the point. At the beginning of the next accumulator period for the point, the internal accumulated value and quality flags for the current period are transferred to the point value and quality, before the internal accumulated value and quality flags are reset. Continuous accumulation periods are not available for completed value type. 4.2.3.6 Quality Propagation
The quality for a CAP is derived from the quality of the TAP, using the same rules as defined for the Calculation subsystem quality propagation, unless otherwise stated. This is described in Calculations, Section 9.7.6. 4.2.3.7 Recovery From Out Of Scan
There are situations where RTU accumulators are temporarily not scanned (including scan error, RTU out of scan, master station restart, etc). Provided the RTU has not been restarted and the RTU accumulator has not wrapped around, then the raw count at scan recovery is valid. Failure/Recovery Within an Accumulation Period This is treated as if no error has occurred. On scan recovery, the TAP is updated using the new raw count and the previous raw count (before the failure). The CAP accumulates the delta value of TAP, and the CAP quality becomes good (because TAP quality is propagated to CAP).
hr Completed
cmpt
140 120 hr Current Telem (delta)

5 5F 5F 5F
145
120F
120F
120F
20
Scan Rate = 1 min
09:10 Last Good Scan
09:11 Scan Failure
09:12
09:13
09:14 Scan Recovery
09:15
09:16
No RTU accumulator wrap around, thus the delta value is added to the CAP, quality becomes good.
Failure/Recovery Over an Accumulation Period End For the TAP, this is treated as if no error has occurred. On scan recovery, the TAP is updated using the new raw count and the previous raw count (before the failure).
4 Core SCADA
For the CAP, the CAP value will have already been reset to zero at the end of the period. For the new period, the CAP accumulates the delta value of TAP. However, some of the delta value does not belong to the new period. To indicate this, the CAP is marked suspect for the rest of the new period.
hr Completed
cmpt
120F 120 hr Current 120F
cmpt
120F
cmpt
Scan Rate = 1 min Reset to zero

20
Telem (delta)
5 5F 5F 5F
20S
25S
5
09:29 Scan Failure
0F 09:30 End of Period
09:31
0F
09:32 Scan Recovery
09:33
09:34
Some of the delta value does not belong to this period. So the CAP is marked suspect for the rest of the period.
4.2.3.8
Discontinuity in RTU Accumulator Data
When there is a discontinuity in the RTU accumulator data (including RTU Accumulator Wrap Around, RTU Accumulator Bad, RTU Restart, etc), then the first raw count (with the condition) is only used to re-establish a reference for calculating subsequent delta raw counts. Note that a discontinuity such as RTU Restart is likely to cause a short period of scan failure (as per the example diagrams), whereas a discontinuity such as RTU Accumulator Bad may not have a preceding period of scan failure. RTU Accumulator Bad Data Status Conitel can report Accumulator Bad Data Status from the RTU (an indication in the Remote Status Word). Note that this is set for RTU accumulator wrap around and other RTU accumulator problems. There is only one flag per RTU, thus if set it causes all accumulators in the RTU to be treated as bad. DNP3 does not currently provide an indication of Accumulator Bad Data Status from the RTU. RTU Accumulator Wrap Around Detection (or the lack of it) Because some protocols/RTUs do not provide an indication of discontinuity in the RTU accumulator data and therefore cannot be detected, it is the users responsibility to decide if TAP and CAP values are correct following any disruption. For example, where the protocol is DNP3, and a RTU accumulator wraps around during a long communications failure. Discontinuity Within an Accumulation Period Upon detection, the TAP value is not updated from the raw count, but the TAP input bad quality flag is set, which in turn sets the CAP input bad quality flag. The next raw count is used to update the TAP. The CAP accumulates the delta value of TAP. The CAP input bad quality flag remains set for the rest of the accumulation period.
Page 112 of 215
4 Core SCADA
hr Completed
cmpt
120 hr Current Telem (delta)

5
120F
120F
120F
120B
125B
Scan Rate = 1 min

5F 5F 5F 5
0B
09:03 Scan Failure
09:04
09:05
09:26 Scan Recovery
09:27
09:28
For a discontinuity in the RTU accumulator data, the first raw count is not used as a delta. The CAP value is marked bad for the rest of the period.
Discontinuity Over an Accumulation Period End There is no additional processing if an accumulation period end has occurred during a discontinuity. The CAP value will have already been reset to zero at the end of period.
hr Completed
cmpt
120F 120 hr Current Telem (delta)

5 5F 5F
cmpt
120F
cmpt
120F
Reset to zero
Scan Rate = 1 min

5
5F
0B
09:29 Scan Failure
0F 09:30 End of Period
0F 09:31
0B 09:54 Scan Recovery
5B 09:55 09:56
For a discontinuity in the RTU accumulator data, the first raw count is not used as a delta. The CAP value is marked bad for the rest of the period.
4.2.3.9
Master Station Failure/Restart
If the station fails and is then restarted, processing is as described for recovery from out of scan (Section 4.2.3.7). If the station was down over a period end, CAP values will not have been stored in history. Therefore on station restart, CAP values are published with the period end time for history storage. Processing does not commence until the TAP initial status flag has been cleared. 4.2.3.10 Manual Override
If the TAP is manually overridden, the CAP suspect quality flag is set. The desired per minute delta raw count or delta engineering value is entered as the manual override value (according to the type configured). The CAP accumulates the TAP delta value every minute. Refer diagram below. If the accumulation period completes before manual override is removed, the CAP value is zeroed at the start of the next period, and the suspect flag remains set.
Page 113 of 215
4 Core SCADA
When manual override is removed, the RTU accumulator is demand scanned and the raw count is used to re-establish a reference for calculating subsequent delta raw counts. Thus RTU accumulations while in manual override are ignored (based on the philosophy that manual override is used for a transducer failure, RTU accumulator failure, etc). The suspect flag remains set for the rest of the accumulation period.
hr Completed
cmpt
hr Current 20 20S
24S
28S
32S
34S
39S
Telem (delta)
5 7M 4M
Manual value is accumulated at a 1-minute rate.

4M 4M 4M 0
Subsequent scans are as for normal processing, suspect remains set for the rest of the period.
5 2
09:10 09:11 Manual Manual Override Value
09:12
09:13 Override removed
09:14 Next Scan
09:15
09:16
Scan Rate = 1 min
This demand scan establishes the reference for subsequent scans.
4.2.3.11
Database Install
Incremental Install When the parameters of a TAP or CAP are changed and incrementally installed, the following should be noted: When changing the accumulation period of a CAP, it changes the current period end time to the appropriate end time based on the new period. Thus the current accumulation is not lost. For example, at 09:35am, a CAP period is changed from a 1-day period to a 1-hour period. At 10:00am, the CAP will have a value for 10 hours, and then is reset to zero ready for the accumulation from 10:00am to 11:00am.
Full Install When the parameters of a CAP are changed and full installed with warmup, the current accumulation is not initialized. Without warmup, processing depends on the stale data in the point.
4.2.4
Time Tags
When a database point value is updated, a time tag is stored in the point. The time tag may be generated by: RTUs that support time tagging of digital state changes and analogue delta changes (e.g. a RTU50 using DNP protocol). Typically the time tag resolution could be 1 milli-second. FEP time stamps the data if the data is not remotely time stamped. Resolution is 1 second. Core SCADA may time stamp the data (e.g. manual change, point substitution). Resolution is 1 second. The time tag is stored in the point, at the resolution provided by the source. The highest supported time tag resolution is 1 millisecond. The time tag is also used in any alarm, event, off-normal and history generation. Some subsystems round off the time tag to a resolution specified for the point. To avoid incorrect times entering the system from the RTU, time tags are checked against the current system time. If the difference from the system time is greater than the future time difference system constant (typically 10 sec) or less than the past time difference system constant (typically 2 days), the data is rejected. An error is logged if data is rejected.
4 Core SCADA
There are cases where the data could be quite old (e.g. if low frequency data collection is configured, or RTU is manually out of service, etc, then the data could be held in the RTU for a significant time before being retrieved). Data with an old time tag is still processed the same. This could make the points time tag go back in time, where say a manual override has been applied and removed since the last scan. For communications failures, Retrospective History processing can be configured instead. Because changes are buffered in the RTU, there could be several changes for the same point. If more than one time tagged data message is received for one point, updates are performed in the order the data is received (it is assumed the RTU returns all time tagged data in sequence). Multiple changes of the same point may cause the Alarm, Event and Off-Normal Lists to shuffle in rapid succession. Note that since calculations continue to be performed as scheduled, calculations may have already run and used old data that may not reflect the true state of field equipment. Conitel SOE time tagged event processing is described in Section 4.2.5. 4.2.4.1 Retrospective History Processing After a Communications Outage (Optional)
Retrospective history processing provides a method of keeping the system up to date with current field data, while a large number of old events are collected from a RTU, following recovery from a communications failure. Only the DNP and IEC101 communications protocols support it (refer Section 3.4.4.6). This option is not recommended because RTU events are not fully processed, causing alarms, etc., to be discarded. Processing is as follows: All static scan data (e.g. DNP class 0) is processed normally to keep the system up to date. The first static scan is scheduled immediately (regardless of the configured scan rate), so that all current values are collected from the RTU as soon as possible. All event scan data (e.g. DNP class 1, 2, and 3) is processed as follows for historical purpose: Events are generated. History is stored (refer Section 10). Current values of database points are not updated. Alarms and off-normals are not generated. Supervisory controls are not inhibited. Events are generated from digital scan data as for normal data from the RTU. There is no alarm processing, therefore analogue scan data does not generate events. The current attributes of the point are used in processing the data (these may have changed since the time tagged data was buffered in the RTU). If the processing generates an event, it is given the time tag of the data. Most events from RTU time tagged data will be seen in the Event List between the event for RTU communications failure and the event for RTU communications restore. Event scan data also includes RTU events that have occurred after communications recovery while in the catchup mode. These events are still processed as per retrospective history, even though the static data scans will have already performed normal processing. This allows accurate occurrence times, and multiple changes to be detected, during catchup mode. This may cause a double entry in the Event List, with the RTU event from the event scan being earlier and more accurate (e.g. in milliseconds). The History subsystem is generally not affected, because of the presentation methods. Retrospective history processing is complete when catchup mode is complete. All of the returned data from the combined scan request (at the end of catchup mode) is treated as current rather than historical data for point processing.
4.2.5
Conitel SOE Processing
Conitel SOE messages generate Event List entries only. They are not used to update the points current value, generate Alarms, or Off-Normal List entries. They cannot be suppressed by the points event attribute. These Event List entries have milli-second resolution. For two-bit digitals, the Conitel SOE Event List entry shows the new point state (i.e. one of four states), not the individual contact states. If the SOE buffer in the RTU overflows, an event is entered in the Event list, to indicate that SOE event messages have been lost.
4 Core SCADA
4.3
Database Objects (Points)
Database objects represent physical points. The standard system supports analogue, digital and accumulator database points. Points may be: Telemetered Control Calculated Manual the current value is input from a RTU. the point can be used to send control operations to a RTU. the current value is a calculated value. the current value is entered by the operator.
4.3.1
Point Quality
Data quality and its indication are important aspects of the iSCADA System. Data quality is good if everything associated with the generation of the data is normal. When not good, the data may still be useful, depending upon the reason. If desired, the operator may manually override a telemetered value and enter a sensible value, e.g. where a transducer is giving erroneous values. If this manual value is input to a calculation, the result point is flagged suspect. The quality handling system supports 64 quality flags. Each flag indicates a condition of the point and may change the processing of that point. The quality flag number (bit number) is shown in column #. Data quality is presented to the user in the form of runtime annotation characters (refer Section 2.5.1). Quality flags are categorized into: Administrative tags that are set/cleared by the operator (see ad in the table below). The Administrative Tags List has an entry for each administrative tag that is set on each point. Status flags that are set/cleared by the software. Some point processing facilities are optional (see op in the table below). The optional facilities are enabled/disabled via the Database Configurator, on a per point basis. Some quality flags can be used to inhibit controls (CI), inhibit alarm generation (AI), inhibit event generation (EI), and inhibit off-normal generation (OI). The table below shows the recommended settings for those flags. They can be changed using the Database Configurator (in Common Data), on a per domain basis. Flag states marked F in the table are fixed in software. Operator Tags are typically renamed for specific customer purposes, with the desired inhibit actions. If a quality flag, that has alarm inhibit, changes state, then alarm conditions are re-calculated (refer Section 5). If a quality flag changes to cause event inhibit, then the change of this quality is recorded in the events list before applying the inhibit. This enables the inhibit action to be traced in the Event List. Operator action events for points are always generated, regardless of whether the point is event inhibited or not. Quality Flag Authorized Change
# Ad Op CI AI EI OI
16
Control Reserved Manual Override Substitute Point Bad
17 19 22
! -
Substitute Point RTU Out Of Scan Point Out Of Scan
21 2 3
! ! !
Description F F F - Y N N N Set after the operator or an application has initiated a control operation to a point. This indicates change of state/value of that point is authorized, therefore do not alarm the change. This is cleared after a digital point has changed state or an analogue has reached the setpoint value. F F F - Y N N N Set to reserve exclusive control of a point. - N N N N Set to override telemetered or calculated values. F F F - N N N N For telemetered points when substitute point is ON, it is set (and the point value is unchanged) if: the source point has bad data quality. no copy of the source point is accessible. - N N N N Set when substitute point is ON. - N N N N Set when an RTU is put out of scan. - N N N N Set when a point is put out of scan.
Page 116 of 215
4 Core SCADA
Scan Error
RTU On Test Point On Test Device Forced Data
0 1 56
Device Offline
59
Device Comms Lost
57
Input Bad
Conversion Error
26
Over Range
24
Under Range
25
- N N N N For telemetered points, to indicate that there is a communications failure between FEP and the RTU. The point value is unchanged. Includes: single scan failure. comms line failure, etc. RTU failure, etc. The scan error flag is cleared when RTU scanning recovers, and the point has a scan value from the RTU (even if the point is out of scan), or immediately if the point has no input (e.g. control point with no feedback). For calculated points the flag is propagated from a source point of the calculation. ! - N Y N Y Set when an RTU is put into test mode. ! - N Y N Y Set when a point is put into test mode. - - N N N N This flag is returned from the RTU: For DNP, to indicate that the value of the data is being overridden at other than where the data originates. For IEC101, this is the SB bit (Substituted), to indicate the value of the Information Object is provided by input of an operator or by an automatic source. For other protocols, this is not used. - - N N N N This flag is returned from the RTU: For DNP, to indicate that the device collecting or originating this data is disabled. Typically, this is set when the data source is invalid (e.g. when a SALL program stops/fails). For IEC101, this is the NT bit (Not Topical). A value is topical if the most recent update was successful. It is not topical if it was not updated successfully during a specified time interval or it is unavailable. For other protocols, this is not used. - - N N N N This flag is returned from the RTU: For DNP, to indicate that there is a communications failure between where the data originates and the RTU. The point value is from the last data reported. For IEC101, this is not used. For other protocols, this is not used. F F F - - N N N N For telemetered points, it is set (and the point value is unchanged) if: transducer is outside ADC range. multi-state input is outside the valid range. any other conversion error. the RTU sends back an indication that the particular data is in error. For calculated points, it is set if: a result is outside the defined engineering range. a source point has the input bad quality flag set. When data is returned from an inter-station request, this flag may be set in the response for the following reasons: the LAN has failed. the station containing the database point has failed. - Set when an invalid input conversion is encountered (e.g. BCD input invalid, a conversion cannot be computed). - ! Set for: telemetered analogue: ADC over range. telemetered/calculated digital: above state maximum. calculated analogue: above engineering maximum. - ! Set for: Page 117 of 215
4 Core SCADA
Calculation Error Device Over Range
28 61
Device Reference Error
62
Device Invalid
63
Initial Status
- N
Initial Database Load Device Restart
32 58
- N
Suspect
33
- N
Operator Tag 1-8 Software Tag 1-8 Alarm Inhibit Better Alarm Inhibit
815 4855 18 27
! !N -
telemetered analogue: ADC under range. telemetered/calculated digital: below state minimum. calculated analogue: below engineering minimum. A calculated point is marked with calculation error if a calculation exception occurs. This flag is returned from the RTU: For DNP, to indicate that the value in the RTU has exceeded its valid range, and therefore the point value is incorrect (for analogue points only). For IEC101, this is the OV bit (Overflow), to indicate the value of the information object is beyond a predefined range of values. For other protocols, this is not used. This flag is returned from the RTU: For DNP, to indicate that the analogue to digital conversion is not being performed accurately and therefore the point value may not be correct (for analogue points only). For IEC101, this is not used. For other protocols, this is not used. This flag is returned from the RTU: For DNP, this is not used. For IEC101, this is the IV bit (Invalid). A value is valid if it was correctly acquired. After the RTU acquisition function recognizes abnormal conditions of the information source the value is then marked invalid. The value of the information object is not defined under this condition (i.e. the value may be incorrect and cannot be used). For other protocols, this is not used. F F F N N N Set after station restart. Indicates field values are unknown. It is not set for manual points, points in manual override, or a study/simulation database. For telemetered points, it is cleared after the first scan of that point. For calculated points, it is cleared after first calculation of that point is performed. Set when point is added to the database. Internal use only. N N N This flag is returned from the RTU: For DNP, to indicate that the device reporting the data value is presently restarting, or the RTU has not updated the value since RTU restart. The point value is not updated. For DNP and Conitel telemetered accumulator points, to indicate RTU restart. For IEC101, this is not used. For other protocols, this is not used. N N N A result point of a calculation is marked suspect if one of its source points is has manual override or point substitution. A result point of a history transform is marked suspect if more than a specified percentage of samples are bad. N N N User definable.
! N N N N Project specific. Set and cleared by application.
! - N YF N N Set to inhibit a point from generating alarms. ! ! N YF N N Set to inhibit a point from generating alarms when its value traverses from a worse alarm zone to a better
Page 118 of 215
4 Core SCADA
Low Alarm Inhibit High Alarm Inhibit In Low Alarm In High Alarm Control Inhibit Off-Normal Entry Inhibit Event Inhibit
40 41 36 37 44 20 42
! ! ! !
- N - N ! NF ! NF F - Y - N
Y Y
F F F F
N N N N
F F
N N N N
F F
N N
N N
N
F
N Y
! - N N YF N
Zone Event Inhibit Device Chatter
43 60
! ! N N NF N - N N N N
Flash
Alarm_R4_State A Alarm_R4_State B Alarm_R4_State C Alarmed Off Normal Authorised State Flat Enabled Flat State Flat Alarm State Flat Flash State Flat Offnormal State Retrospective History Edited History Missing Data
29 30 31 38 39 34 35 23 45 46 47 -
alarm zone. Set to inhibit low limit/zone alarms. Set to inhibit high limit/zone alarms. Set if current value is in low alarm zone. Set if current value is in high alarm zone. Set to inhibit control of a point. Set to inhibit a point from generating an Off-Normals list entry. Set to inhibit an analogue point from generating events when its value traverses alarm limits/zones (including normal zone). Set to inhibit a digital point from generating events specified by the event attribute for that point. Set to inhibit a point from generating events when its value traverses alarm zones (other than normal zone). This flag is returned from the RTU: For DNP, to indicate that the value in the RTU is presently being filtered because it is changing rapidly (for digital points only). For IEC101, this is not used. For other protocols, this is not used. Set by software when an alarm is annunciated. It indicates a point is alarmed and is not acknowledged. The display symbol or value flashes. Cleared by the operator when all alarms associated with the point are acknowledged. Alarm sub-system internal use only. Alarm sub-system internal use only. Alarm sub-system internal use only. Alarm sub-system internal use only. Alarm sub-system internal use only. Core SCADA sub-system internal use only. Flat alarm sub-system internal use only. Flat alarm sub-system internal use only. Flat alarm sub-system internal use only. Flat alarm sub-system internal use only. Flat alarm sub-system internal use only. This flag is only used in history samples (not in points). Set to indicate that the history data came from buffered data and was stored retrospectively. This flag is only used in history samples (not in points). Set to indicate that the history data has been edited. This flag is only used in history samples (not in points). Set to indicate that the history data was unavailable for collection.
4.3.2
Bad Data
Bad Data Definition
There are two levels of indication for bad quality of data.
This is the main indication that data is bad (for any of several reasons). The data should not be relied upon. This is used by the software to avoid including the value in processing, which would give misleading results. Bad Data processing is described in iSCADA System Functional Specification Sections that use it. Bad Data is overridden if the point has manual override set. There is no quality flag for Bad Data, the software masks several bits together for checking. The definition of Bad Data is fixed in software (see Runtime Annotation Quality diagram).
Page 119 of 215
4 Core SCADA
Currently, Bad Data does not take point substitution into account. If point substitution is ON, the receiving point is still used for the Bad Data mask, and the quality of the source point is not considered. Individual Quality flags (point out of scan, scan error, input bad, etc) These individual flags give the reason for the bad data indication. For example, they are used by the HMI to display the runtime annotation. Each has its own annotation (thus the user can analyze the quality flags in detail, to see the reason for bad data). The input bad flag most commonly means the data was received but could not be converted. It can be set for several conditions (refer table in Section 4.3.1).
4.3.3
Quality Flag Propagation (Runtime)
The following diagram shows how the raw database conditions of a point are combined to produce a Runtime Annotation Quality. This is used when displaying points from the realtime database. There are also propagation diagrams for Calculations (refer Section 9.7.6) and History (refer Section 10.1.4), which use/combine the quality flags in other ways as applicable.
Page 120 of 215
4 Core SCADA
Bad Data is when any of the shaded flags are set. This is overridden by Manual Override and Substitute Point. Indicates which HMI list may show points with that flag set.
RAW QUALITY FLAGS

Authorised Change No List Control Reserved Manual Override Substitute Pt Bad Substitute Point RTU Out Of Scan Point Out Of Scan Scan Error RTU On Test Point On Test Dev Forced Data Dev Offline Dev Comms Lost Input Bad Conversion Error Over Range Under Range Calculation Error Dev Overrange Dev Ref Error Dev Invalid Initial Status
Initial Database Load
RUNTIME ANNOTATION QUALITY

Authorised Change Control Reserved Manual Override Substitute Pt Bad Substitute Point RTU Out Of Scan Point Out Of Scan Scan Error RTU On Test Point On Test Dev Forced Data Dev Offline Dev Comms Lost Input Bad No List Tags List No List Tags List No List Tags List No List No List Tags List Event List Event List No List (see driving flags) Off-Normal List Off-Normal List Off-Normal List No List Event List Event List Event List No List No List No List No List Tags List No List Tags List Tags List Tags List Tags List Alarms List Alarms List Tags List Tags List Tags List Event List No List In High Alarm In Low Alarm Control Inhibit Off-norm Entry Inh Event Inhibit Zone Event Inh Dev Chatter Flash Dev Restart Suspect Operator Tag 1-8 Software Tag 1-8 Alarm Inhibit Initial Status Does not go to Event List (like other Dev flags), because condition is likely on many points and will generate many events.
Dev Restart Suspect Operator Tag 1-8 Software Tag 1-8 Alarm Inhibit Better Alarm Inh Low Alarm Inh High Alarm Inh In High Alarm In Low Alarm Control Inhibit Event Inhibit Zone Event Inh Dev Chatter Flash
Off-norm Entry Inh Tags List
Page 121 of 215
4 Core SCADA
4.4
Core SCADA Initialization
After a station restart, the station undergoes an initialization phase prior to operation as follows: SCADA objects are loaded from the database and transient lists built. Set up initial flags as described in Section 4.3.1. Perform point synchronisation with the highest precedence copy of the point. It is likely that during restart it is determined that the point is to become the primary point and take over from an existing backup point. Re-calculate alarms (refer Section 5). Re-generate Administrative Tags List. The date/time of all entries is initialized to the restart time. Note that the Administrative Tags List only contains entries for currently existing conditions. When a station fails, the entries continue to be updated from backup stations, where available. Where redundant database stations are not available, any entries that originated from a failed station, prior to its failure, are removed. The History Subsystem is responsible for catch-up of missed historical samples (refer Section 10). Initiate scanning functions.
Page 122 of 215
5 Alarm Management
ALARM MANAGEMENT
An analogue point has a high limit, a low limit and up to 127 alarm zones for each limit. The width of successive zones is an exponential series of the width of the first zone. Critical high and low alarm limits are defined as particular high and low alarm zones (system wide). Analogue zone alarms are annunciated when an analogue point enters/exits an alarm limit or crosses zone boundaries. There is a deadband on return to a better zone and to normal zone. The current alarm zone is shown in the Alarm List. An analogue point can also have flat line detection. A flat line alarm is annunciated if the value has not changed significantly for a given time period. Flat line alarms are independent of zone alarms, and have separate alarm list entries. Any change in analogue alarm conditions generates an event. Analogue points that are outside their normal operating range or in flat line are flagged as being off-normal. Digital points can be configured to generate an alarm when the point enters/exits particular states. They can be also configured to generate an event when the point enters/exits particular states. A digital point is flagged as being off-normal if it is not in its configured normal state.
5.1
5.1.1
Analogue Alarms
Zone Alarms
Analogue zone alarms can be generated for all types of analogue points (including accumulators). Each point can have a high and low limit configured, which can be changed online. The high and low limit can be individually inhibited online. An analogue point that is within its normal operating zone (normal zone) is in alarm zone zero. On crossing1 its high/low alarm limit, the value enters zone 1, and an alarm is annunciated. As the value crosses1 into each new zone, the alarm is re-annunciated. This is known as a worse alarm, when the point value changes from any alarm zone to a worse zone, on the same side of normal zone. As the value returns towards the normal zone, re-entering each zone, the alarm is re-annunciated. This is known as a better alarm, when the point value changes from any alarm zone to a better zone, on the same side of normal zone. Upon return to the normal zone, the alarm is re-annunciated as an exit alarm (i.e. return to normal). A point value change from any high alarm zone to any low alarm zone, or from any low alarm zone to any high alarm zone, is treated as a new alarm. Note 1: A point only changes its alarm condition when it crosses the zone boundary. Thus a point value equal to the boundary is still in the same zone and its alarm condition does not change.
Page 123 of 215
5 Alarm Management
Engineering High Range /ADC High Range Limit
Over Range Zone <= 127 etc... Zone 2 Zone 1 (primary zone) Normal Zone (Zone 0)
In Alarm: Off-Normal: In Alarm: Off-Normal:
No Yes Yes Yes
High Alarm Limit
In Alarm: Off-Normal:
No No
Low Alarm Limit
Zone 1 (primary zone) Zone 2 Zone <= 127 etc...
Engineering Low Range /ADC Low Range Limit
Under Range
5.1.1.1
Zone Width
Zone 1 is called the primary zone. Each analogue point has one high and one low limit primary zone width configured (in engineering units). The primary zone widths can be changed online. The width of each successive zone is an exponential function of the width of the primary zone. Each analogue point has one high and one low zone exponent selector configured. The zone exponent selectors cannot be changed online. The zone exponent selector is in the range -7 to +7: Zero - makes all zones the same width. Less than zero - makes successive zones smaller. Greater than zero - makes successive zones larger.
(selector/8)
The actual formula used is: Zonen+1 = Zonen * S Where: 5.1.1.2
S is the series factor, fixed in software to 1.27. Number of Zones
The number of zones for the high or low limit of a given point depends on how many zones fit between the alarm limit and the engineering range limit. The last zone (e.g. zone 4 below) fills up the remaining space from the previous zone to the engineering range limit. The number of zones may be different for high and low.
Engineering High Range /ADC High Range Out of Range Zone 4 Zone 3 Zone 2 Zone 1 High Limit Zone 0 In this example, only 3 whole zone widths will fit. Therefore zone 4 is the remaining width, between zone 3 and the engineering high range limit.
The maximum number of alarm zones (i.e. the highest zone number) for a system is set by a system constant (up to 127 zones). If more zones than this maximum number (e.g. 8 below) fit between the
5 Alarm Management
alarm limit and the engineering range limit, then the last zone (e.g. zone 8 below) fills up the remaining space from the previous zone to the engineering range limit.
Engineering High Range /ADC High Range Out of Range Zone 8 Zone 7 Zone 6 Zone 5 Zone 4 Zone 3 Zone 2 Zone 1 Zone 0 In this example, a maximum of 8 zones has been defined for the system. For this point, more than 8 zone widths will fit. Therefore zone 8 is the remaining width, between zone 7 and the engineering high range limit.
High Limit
5.1.1.3
Deadbands
A deadband prevents the generation of multiple zone alarms when an analogue point is hovering at an alarm zone boundary. The deadband value is applied to the inside of the zone boundaries. A value is considered to have changed to a better zone only when it has crossed the deadband. There are two types of deadbands configured per analogue point, which can be changed online. A zone 0 deadband - applies to points returning to zone 0. It is specified as a percentage of the zone 0 width. An interzone deadband - applies to points moving from a higher to a lower zone number (except zone 0). It is specified as a percentage of the zone width. Consequently, smaller zones have a smaller interzone deadband, and larger zones have a larger interzone deadband.
The diagram shows an analogue point going high then returning, with the alarm list entry text (e.g. HI ALM 1) and the point value annotation (e.g. 100 HI).
WRS 2 118 H WRS 2 121 H
Zone 2
WRS 2 121 H
120 116
Interzone Deadband Not considered exited zone 2 Zone 1 (Primary zone)

BTR 1 115 H
ALM 1 101 H
100
High Limit Zone 0 Deadband

BTR 1 99 H RTN 0 89 X
90 Zone 0 (Normal Zone)

87
5.1.1.4
Critical High/Low Limits
The high alarm zone that corresponds to critical high, for all analogue points in a system, is set by a system constant. The low alarm zone that corresponds to critical low, for all analogue points in a system, is set by another system constant.
5 Alarm Management
A better alarm that crosses the critical high/low limit and is still in high/low alarm is marked as exit critical high/low. A better alarm that crosses the high/low limit is marked as exit high/low. Acknowledging the alarm removes any exit critical high/low or exit high/low marking, so that the alarm condition indicates high/low or no alarm, respectively. The diagram shows the runtime annotation that would be displayed for an analogue point going high, then critical high and back to normal. Treatment of low alarm and critical low alarm is similar.
ACKN (has no affect on annotation) 120 CH 100 Critical High Limit 110 CH 90 XC 80 H 60 H High Limit 40 30 X ACKN 20 20 50 H ACKN (If not acknowledged here, then XC changes to X on return to normal. 150 CH CH = Critical High Alarm CL = Critical Low Alarm XC = Exit Critical Alarm H = High Alarm L = Low Alarm X = Exit Alarm
120 CH
5.1.1.5 Alarm List
Display of Alarm Condition
The entry in the Alarm List shows the current alarm zone number and whether the alarm is new, getting better or worse, or return to normal. Deadbands are taken into account (i.e. there is no change until clear of the deadband). Runtime Annotation For point runtime annotation and some other display types such as gauges and bar graphs (refer Section 2.5.2), the alarm condition is displayed in terms of high/low alarm and critical high/low alarm, rather than alarm zone number. The runtime annotation indicates if the point is in high/low alarm, critical high/low alarm, or just exited from alarm or from critical alarm. Deadbands are taken into account (i.e. there is no exit until clear of the deadband).
5.1.2
Flat Line Alarms
Analogue flat line alarms can be generated for all types of analogue points (including accumulators). Each point can have a flat line deadband and detection period configured, which can be changed online. The flat line alarm functionality can be enabled/disabled via the Configurator and can be changed online. The flat line alarm functionality is independent of the zone alarm functionality (Section 5.1.1). This means a separate alarm list entry, off-normal list entry, acknowledge and delete. Thus, the flat line alarm condition can be viewed and handled independently of the point being in (say) high alarm. An analogue flat line alarm is annunciated if the analog point value has not changed significantly for a given time period. The value range for a significant change is defined by the flat line deadband. The time period is defined by the flat line detection period. The annunciation time tag is the time at the end of the time period. If the value remains in the flat line deadband for a further flat line detection period, the analogue flat line alarm is re-annunciated, and so on. The annunciation time tag is the time at the end of the time period. When the value changes significantly (i.e. moves out of the flat line deadband), the flat line alarm is reI/A Series Intelligent SCADA System Page 126 of 215
5 Alarm Management
annunciated as an exit alarm (i.e. return to normal). The annunciation time tag is the time stamp of the value.
Flat line return alarm annunciated Flat line alarm annunciated Deadband applied after significant change Flat line detection period Flat line alarm re-annunciated
Flat line detection period
Deadband applied initially
Significant change Initial value
The flat line detection period is restarted, and the deadband is moved such that its midpoint is the current point value, whenever: The value moves out of the flat line deadband (be it currently in flat line alarm condition or not). After any of flat line alarm parameters are changed.
Note: the flat line alarm functionality still applies when the point is in manual override or point substitution.
5.2
Digital Alarms
Digital alarms can be generated for all types of digital points. Each point has an alarm state definition configured, to specify which point states are to annunciate an alarm. It can be when the point enters a given state, its normal state, or never, etc. The alarm state definition is independent of the normal state definition (unlike an analogue point where the relationship is fixed). For example, it is possible to configure a point to be in alarm when it is in its normal state. For 2 and 4 state digital points, the Alarm State Definition can be any one of the following: No alarm state. State A is alarm state. State B is alarm state. State A and B are alarm states. Off-normal state is alarm state (off-normal to off-normal is not annunciated). Normal state is alarm state. Normal state and off-normal states are alarm states (note: all states are alarm states) (off-normal to off-normal is not annunciated). All digital states are alarm states.
For multi-state digital points, the Alarm State Definition can be any one of the following: No alarm state. All digital states are alarm states.
An alarm is annunciated when the point state changes to a configured alarm state. This includes changes from other alarm states, except as noted in the Alarm State Definition above. Upon return to a non-alarm state an alarm is normally not annunciated. Optionally, return to a nonI/A Series Intelligent SCADA System Page 127 of 215
5 Alarm Management
alarm state can be alarm annunciated (known as a digital return alarm). This is set in a system startup file and applies system-wide. Digital return alarms are effective with all Alarm State Definitions that have a non-alarm state (note: before rev 6.1, digital return alarms were only effective with the Alarm State Definitions Off-normal state is alarm state and Normal state is alarm state).
5.2.1
Annunciation of Transient Digital States with DNP Protocol
The DNP protocol uses RTU event scanning for data acquisition. For two bit status inputs, each input change causes a separate RTU event. When the field device changes from open to close (or close to open), both inputs change state. This causes a transient state, which may generate an alarm/event. If a transient state alarm/event is not required then: An alarm/event attribute that masks out these transient states can be used. For example, alarm any change of state would cause a transient state alarm, whereas alarm change to A or B state would not cause a transient state alarm for open to close, or close to open. This may not be desirable, if an alarm/event is normally required when the final state is, say, not A or B. Or, an annunciation time delay can be configured to filter out the transient states.
Note, that the above still applies, where DNP class 0 scanning is used instead of event scanning, due to the method of processing.
5.3
5.3.1
Point Quality Alarms (Analogue and Digital)

Cause Alarm
Alarms can be generated for analogue and digital points for nominated bad data conditions (indicated by point quality flags). For example, when an analogue point goes over range, an alarm can be annunciated. Typical cause-alarm point quality flags include under/over range and conversion error. For an analogue point, cause-alarm functions on the zone alarm, but not on the flat line alarm. For a given point quality flag, if the point quality alarm inhibit is configured (refer Section 5.8.5), it inhibits cause-alarm. For a given point, suspend-alarm overrides cause-alarm (e.g. scan error suppresses an over range alarm). Into Cause Alarm When a cause-alarm point quality flag (e.g. over range) becomes set, an alarm is annunciated, even if the point is already in alarm due to the point value, or another cause-alarm point quality flag. Out Of Cause Alarm When a cause-alarm point quality flag (e.g. over range) is cleared: If the point is still in another alarm condition (e.g. high alarm zone 5), then the alarm is reannunciated. Otherwise, return-alarm processing is performed.
Events The cause-alarm annunciation does not cause an event to be generated because an event will have already been generated for the point quality condition (if appropriate). Off-Normals The point is considered as off-normal when in alarm due to cause-alarm point quality flags.
5.3.2
Suspend Alarm (and Data Unavailable)
Suspend-alarm functionality is similar to alarm inhibit by point quality, however with suspend-alarm: Any current alarm indication is not acknowledged and deleted. This allows the operator to see that the alarm has gone bad. The operator can delete the alarm when he wishes to do so.
Page 128 of 215
5 Alarm Management
Recovery from bad data avoids mass re-annunciation.
Into Suspend Alarm For most bad data conditions of analogue and digital points (e.g. scan error), it is not possible to determine if a point is in alarm because the value cannot be accessed. Therefore point value alarm processing is suspended, and the point is considered not to be in alarm. Typical suspend-alarm point quality flags include scan error and point out of scan. For an analogue point, suspend-alarm functions on both the zone and flat line alarm. For a given point quality flag, if the point quality alarm inhibit is configured (refer Section 5.8.5), suspend-alarm has no effect. If the point is currently in alarm: The change to not in alarm does not annunciate a return alarm. The current alarm indication is not acknowledged or deleted. The off-normal entry is removed.
Out Of Suspend Alarm - Analogue Zone and Digital Alarms When points recover from some bad data conditions, mass re-annunciation of previously annunciated alarms can occur, causing the alarm list to be swamped with alarms that the operator has already dealt with. For example, communications are restored to a Remote Device containing many analogue points in high and low alarm. To avoid this mass re-annunciation, a point quality flag such as scan error can be marked as Data Unavailable. Data Unavailable set indicates that the bad data condition (point quality flag) is because the field input cannot be accessed. On recovery from the bad data condition, only points with changed alarm conditions are annunciated (e.g. an analogue point is in a different alarm zone). This avoids re-annunciation of previously annunciated alarms, for mass bad data conditions such as scan error, and also for individual bad data conditions such as point out of scan. Annunciation occurs unless suppressed for another reason. Annunciation time is the current date/time. Data Unavailable clear indicates that the field input can be accessed, and the bad data condition (point quality flag) has resulted from processing that field input (e.g. Over Range). On recovery from the bad data condition, any currently suppressed alarm (including return alarms) is re-annunciated as for a new alarm with the current date/time, unless suppressed for another reason. In the unlikely event that a both types of recovery occur and are detected at exactly the same time, an unchanged alarm condition could still possibly get annunciated, depending on the order of detection in alarm processing. Out Of Suspend Alarm - Flat Line Alarms For analogue flat line alarms, any currently suppressed alarm is not re-annunciated, because flat line detection will eventually re-annunciate a flat line condition anyway. The detection mechanism continues, unaffected by the bad data condition, using the value on recovery as the next value. If the detection period expires during the bad data condition, action is deferred until recovery; the value on recovery is then used to determine if a flat line condition exists. Note: For long failures, the detection period is likely to have elapsed on recovery. The detection period may also have elapsed on recovery, during a short failure, with say unreliable communications, where there may be many short failures.
5.3.3
Cause-Alarm and Suspend-Alarm Point Quality Flags
The cause-alarm, suspend-alarm and data unavailable settings for each Bad Data point quality flag are nominated by system constants that apply system wide. Default settings are as follows: Bad Data Point Quality Flag Flag # Cause-Alarm Suspend-Alarm Data Unavailable
Page 129 of 215
5 Alarm Management
Substitute Point Bad RTU Out Of Scan Point Out Of Scan Scan Error Initial Database Load Initial Status Conversion Error Over Range Under Range Calculation Error Device Over Range Device Ref Error Device Invalid Device Offline Device Comms Lost Device Restart Device Chatter
22 2 3 5 32 4 26 24 25 28 61 62 63 59 57 58 60
Y N N N not used N Y Y Y N N N N N N N N
N Y Y Y not used N N N N Y Y Y Y Y Y Y Y
N Y Y Y not used Y N N N N N N N N N N N
5.4
Alarm Annunciation
Alarm annunciation may be to announce a new alarm, a change in alarm condition, exit from alarm, or removing an alarm inhibit on a currently suppressed alarm. The unacknowledged alarm causes the point display on all windows to flash. The runtime annotation is updated (e.g. an analogue point goes into high alarm or flat line). This occurs regardless of the operators areas of responsibility. If the point belongs to an operators areas of responsibility, then: The Alarm List display shows a new entry, or if there is an existing entry it is updated, with the date flashing. The 3-Most Recent Alarms Window is updated. The Alarm List button changes colour. When there are any unacknowledged/acknowledged alarms in an alarm group, the associated Control Window alarm group button changes colour (refer Section 2.4.3). The audible alarm is sounded, and the HMI Command Window Audible Alarm button flashes (refer Section 2.4.1.1).
For analogue points, alarm annunciation generates an associated event and off-normal. For digital points, there are no associated events and off-normals. Refer Sections 5.9 and 6.7.
5.4.1

Authorized Controls
For authorized changes of analogue setpoint control points: No alarm is annunciated for the final value, or for any intermediate values. An event is generated to indicate an authorized change has occurred. If the point changes alarm zones, an event is generated. The control action does not affect off-normal generation.
For authorized changes of digital control points: No alarm is annunciated for the final value, or for any intermediate values. An event is generated to indicate an authorized change has occurred, regardless of the alarm state definition. The control action does not affect off-normal generation.
Page 130 of 215
5 Alarm Management
5.4.2
Annunciation Time Delay (Fleeting Change Filtering)
Each analogue and digital point has a configurable annunciation time delay to filter out alarm, event and off-normal generation resulting from fleeting changes. The time delay applies to both entry and exit. If the change still exists after the time delay, then alarm, event and off-normal processing is performed. The annunciation time tag is the time when the time delay was started. The time delay also applies to cause-alarm and suspend-alarm point quality flag changes. For an analogue point, the time delay applies on the zone alarm, but not on the flat line alarm. A change back to the original condition cancels the time delay. Other changes do not affect the time delay. During the time delay the display shows the new point value/state but not annunciated. The zone number and other alarm condition indications do not change. 5.4.2.1 Analogue Points
For analogue points, the time delay applies when entering into alarm, and when returning from alarm. There is no time delay across zone boundaries1. When entering into alarm (transition from normal zone to an alarm zone), zone 0 and interzone deadbands have no effect (because the point is not yet in alarm). The zone at timer expiry is annunciated. When returning from alarm (transition from an alarm zone to normal zone), the time delay is only initiated when the zone 0 deadband has been crossed.
Zone 2 Zone 1 Deadband Timer did not expire: No annunciation (deadband has no effect as point is not in alarm) Timer expires: Annunciate High alarm (HI ALM 2)
Zone 1
Time delay initiated
Timer did not expire: No annunciation
Time delay initiated
High Limit Zone 0 Deadband
Zone 0 Time delay initiated Time delay initiated
Timer expires: Annunciate return alarm (HI RTN 0)
Note 1: There is a time delay if the value changes zone in two steps, with the intermediate value in zone 0. 5.4.2.2 Digital Points
For digital points, the time delay applies to all state changes. When changing state, the new state is annunciated when the timer expires.
alarm attribute: alarm in one state only Timer did not expire: No annunciation Timer expires: Annunciate Alarm Timer did not expire: No annunciation Timer expires: Annunciate Return
Alarm
Non-Alarm
Optional Time Delay on Events and Off-Normals
Page 131 of 215
5 Alarm Management
For digital points, the system is configurable, by a system constant, to operate in one of the following ways: To apply the time delay to alarm, event and off-normal generation. Thus the time delay filters out fleeting changes completely. This is the default. Or, to apply the time delay to alarm generation only. Events and off-normals are generated without delay. Thus the time delay filters out alarms resulting from fleeting changes but leaves a record of these changes in the Event List.
5.5

Alarm Acknowledgement (Visual)
The operator can (visual) acknowledge alarms in the operators areas of responsibility, as follows: From any window, a single point, or whole window of points. From the Alarm List, a single alarm, selected alarms, or whole page of alarms. From the 3-Most Recent Alarms Window, a single alarm.
Alarm acknowledgement can also be configured to be automatic. For audible alarm acknowledgement, refer to Section 2.4.1.
5.5.1

Alarm Acknowledge - Any Window - Single Point
A single point in any window where it is displayed can be alarm acknowledged via the Point Palette. For points, the point display on all windows ceases to flash. The date on the alarm line ceases to flash. The 3-Most Recent Alarms Window is updated. If all alarms relevant to that operator console have been acknowledged, the HMI Command Window Alarm List button reverts to its normal colour. If all alarms in all alarm groups associated with the display call-up button have been acknowledged, the display call-up button changes to its normal colour. An operator action event is generated.
5.5.2
Alarm Acknowledge - Any Window - Whole Window (Solaris HMI Station)
From any window, all points in the window shown by point displays, can be alarm acknowledged in a single operation via the window menu Acknowledge function. Only alarms in the operators areas of responsibility are acknowledged. The Acknowledge option is greyed out if window alarm acknowledgment is not applicable. Each alarm is acknowledged as described in Section 5.5.1.
5.5.3
Alarm Acknowledge - Alarm List - Single Alarm
A single alarm in the Alarm List can be alarm acknowledged via the Point Palette. The alarm is acknowledged as described in Section 5.5.1.
5.5.4
Alarm Acknowledge - Alarm List - Selected Alarms
From the Alarm List, one or more alarm entries can be selected, and then acknowledged. The selected alarms are acknowledged whether the entries are currently visible or not. Each alarm is acknowledged as described in Section 5.5.1. The alarm entries are de-selected.
5.5.5
Alarm Acknowledge - Alarm List - Whole Page
A full window of alarm entries (typically 20 alarms) in the Alarm List can be acknowledged. All
Page 132 of 215
5 Alarm Management
unacknowledged alarms that are visible on the window are acknowledged. Alarms that are not visible are not acknowledged. Each alarm is acknowledged as described in Section 5.5.1.
5.5.6
Alarm Acknowledge - 3-Most Recent Alarms Window - Single Alarm
A single alarm in the 3-Most Recent Alarms Window can be alarm acknowledged. The alarm is acknowledged as described in Section 5.5.1.
5.5.7
Automatic Alarm Acknowledge
Two independent options for automatic alarm acknowledgement are configurable per point. 1. Acknowledge on return: For analogue points, automatically acknowledge upon returning to non-alarm (same as normal state). The return to non-alarm may be due to either a zone alarm returning to the normal zone, or a flat line alarm detecting a significant change, or clearing of a cause-alarm point quality flag. For digital points, automatically acknowledge alarm upon returning to non-alarm or to normal state. The choice of non-alarm or normal state is configurable per point. The return to non-alarm may be due to either returning to a non-alarm digital state, or clearing of a cause-alarm point quality flag. 2. Acknowledge after a time period: For analogue and digital points, automatically acknowledge any alarm condition after a time period since annunciation, regardless of the point condition. The time period is configured on a per point basis.
The alarm is acknowledged as described in Section 5.5.1, except there is no operator action event.
5.6
Return Digital Point to Normal on Acknowledge
A digital point can be configured to change its own digital state to normal (as defined by the normal state definition) after alarm acknowledgement. If the point has no normal state, then no action is taken. The change is processed like any other point state change, and may annunciate an alarm if so configured (refer Section 5.1.1.4).
5.7
Alarm Deletion
The operator can delete alarms in the operators areas of responsibility, if the alarm has been acknowledged, irrespective of point condition. Alarm deletion is initiated from the Alarm List for selected alarms, or whole page of alarms. Alarm deletion can also be configured to be automatic.
5.7.1
Alarm Delete - Alarm List - Selected Alarms
From the Alarm List, one or more alarm entries can be selected, and then deleted. The selected alarms are deleted whether the entries are currently visible or not. The alarm list entries are deleted. An operator action event is generated.
5.7.2
Alarm Delete - Alarm List - Whole Page
A full window of alarm entries (typically 20 alarms) in the Alarm List can be deleted. All acknowledged alarms that are visible on the window are deleted. Alarms that are not visible are not deleted.
5 Alarm Management
The alarm list entries are deleted. An operator action event is generated.
5.7.3
Automatic Alarm Deletion
A point can be configured to automatically delete the alarm, when the alarm has both returned and been acknowledged (manual or automatic). Deletion occurs regardless of the order of return and acknowledge, i.e.: The alarm returns then the alarm is acknowledged. Or, the alarm is acknowledged then returns. Provided this return does not cause re-annunciation (thus become unacknowledged). For example, for an analogue point the return is normally annunciated, and thus becomes unacknowledged. Return means: For analogue points, returning to non-alarm (same as normal state). The return to non-alarm may be due to either a zone alarm returning to the normal zone, or a flat line alarm detecting a significant change, or clearing of a cause-alarm point quality flag. For digital points, returning to non-alarm or to normal state. The choice of non-alarm or normal state is configurable per point (using the same parameter as for auto alarm acknowledge). The return to non-alarm may be due to either returning to a non-alarm digital state, or clearing of a cause-alarm point quality flag. The alarm list entries are deleted. There is no operator action event.
5.8
Alarm Inhibit
Alarm inhibit suppresses alarms. Any current visual effects of the alarm are removed. Alarms in the operators areas of responsibility can be inhibited manually by the operator applying an alarm inhibit, for the following: a) For a digital point: All alarms can be inhibited.
b) For an analogue point: All alarms can be inhibited. High alarms (including high zone alarms) can be inhibited. Low alarms (including low zone alarms) can be inhibited. Better alarms (including exit alarms) can be inhibited.
Alarms can also be inhibited automatically depending on the condition of the point, as signified by the point quality.
5.8.1
Alarm Inhibit/Enable - All Alarms
For any point, all alarms can be inhibited/enabled via the Point Attributes Fascia. For an analogue point, this effectively extends the normal zone to the engineering limits. For an analogue point zone alarm, the associated event and off-normal is also suppressed. For an analogue point cause-alarm, the associated off-normal is also suppressed (note there is no associated event to suppress). When all alarms are inhibited: Any current alarm indication is acknowledged and deleted: The alarm is acknowledged as described in Section 5.5.1. The alarm list entry is deleted.
Page 134 of 215
5 Alarm Management
For analogue points, the associated Off-Normal List entry is deleted. Future point alarms: The alarm will be suppressed. For analogue points, the associated event will be suppressed. For analogue points, the associated off-normal will be suppressed. The point is flagged alarm inhibit. An entry is made in the Administrative Tags List. An operator action event is generated.
When the all alarm inhibit is removed: Any currently suppressed alarm is re-annunciated as for a new alarm with the current date/time, unless suppressed for another reason. Future point alarms will be annunciated, unless suppressed for another reason. The alarm inhibit flag is cleared from the point. The related Administrative Tags List entry is deleted. An operator action event is generated.
5.8.2
Alarm Inhibit/Enable - High Alarms
For an analogue point, high alarms (including high zone alarms) can be inhibited/enabled via the Point Limits Fascia. This effectively extends the normal zone to the high engineering limit. For an analogue point, the associated event and off-normal is also suppressed. When high alarms are inhibited: Any current high alarm indication is acknowledged and deleted: The high alarm is acknowledged as described in Section 5.5.1. The high alarm list entry is deleted. For analogue points, the associated Off-Normal List entry is deleted. Future point high alarms: The alarm will be suppressed. For analogue points, the associated event will be suppressed. For analogue points, the associated off-normal will be suppressed. The point is flagged high alarm inhibit, which also sets alarm inhibit. An entry is made in the Administrative Tags List. An operator action event is generated.
When the high alarm inhibit is removed: Any currently suppressed high alarm is re-annunciated as for a new alarm with the current date/time, unless suppressed for another reason. Future point high alarms will be annunciated, unless suppressed for another reason. The high alarm inhibit flag is cleared from the point, which also clears alarm inhibit (unless set for another reason). The related Administrative Tags List entry is deleted. An operator action event is generated.
5.8.3
Alarm Inhibit/Enable - Low Alarms
For an analogue point, low alarms (including low zone alarms) can be inhibited/enabled via the Point Limits Fascia. This effectively extends the normal zone to the low engineering limit. For an analogue point, the associated event and off-normal is also suppressed. When low alarms are inhibited: Any current low alarm indication is acknowledged and deleted: The low alarm is acknowledged as described in Section 5.5.1. The low alarm list entry is deleted.
Page 135 of 215
5 Alarm Management
For analogue points, the associated Off-Normal List entry is deleted. Future point low alarms: The alarm will be suppressed. For analogue points, the associated event will be suppressed. For analogue points, the associated off-normal will be suppressed. The point is flagged low alarm inhibit, which also sets alarm inhibit. An entry is made in the Administrative Tags List. An operator action event is generated.
When the low alarm inhibit is removed: Any currently suppressed low alarm is re-annunciated as for a new alarm with the current date/time, unless suppressed for another reason. Future point low alarms will be annunciated, unless suppressed for another reason. The low alarm inhibit flag is cleared from the point, which also clears alarm inhibit (unless set for another reason). The related Administrative Tags List entry is deleted. An operator action event is generated.
5.8.4
Better Alarm Disable and Inhibit
For an analogue point, Better Alarm Disable and Better Alarm Inhibit, inhibits alarms from a higher zone number to a lower zone number (on the same side of normal zone), including from any zone to zone 0 (i.e. the exit alarm). An existing entry in the Alarm List does not flash when getting better, but the alarm state texts and the zone number are still updated. 5.8.4.1 Better Alarm Disable (a Configuration Action)
Better alarms can be disabled by configuration. Better Alarm Disable only suppresses the alarms. Associated events and off-normals are unaffected. Note: there is no associated point quality flag, Administrative Tags List entry or operator action event. One point category is nominated as the Better Alarm Disable point category. Points that require better alarm disable are assigned to that category. The Better Alarm Disable point category is nominated by a system constant. Better Alarm Disable is an optional system facility. By default, the system constant does not nominate a category and the Better Alarm Disable facility is not operational. Thus all categories are still available for general use. 5.8.4.2 Better Alarm Inhibit (an Operator Action)
Better alarms can be inhibited/enabled via the Point Limits Fascia. The associated event is also suppressed. The associated off-normal is unaffected. Better Alarm Inhibit is similar to Better Alarm Disable except that: The associated event is also suppressed. Point runtime annotation is displayed because a point quality flag is set. An entry is made in the Administrative Tags List. An operator action event is generated.
When better alarms are inhibited: Note: no current alarm indications are acknowledged and deleted. This is because better alarm inhibit is inhibiting an alarm state change, not a particular alarm state. Future point better alarms: The alarm will be suppressed. The associated event will be suppressed. The associated off-normal will not be suppressed. The point is flagged better alarm inhibit, which also sets alarm inhibit.
Page 136 of 215
5 Alarm Management
An entry is made in the Administrative Tags List. An operator action event is generated.
When the better alarm inhibit is removed: Note: there is no currently suppressed alarm to annunciate. Future point better alarms will be annunciated, unless suppressed for another reason. The better alarm inhibit flag is cleared from the point, which also clears alarm inhibit (unless set for another reason). The related Administrative Tags List entry is deleted. An operator action event is generated.
Inhibiting Better Alarms on a Better Alarm Disable Point If the operator inhibits better alarms on a point that is configured for Better Alarm Disable, the inhibit action overrides the Better Alarm Disable (e.g. better events are suppressed, the inhibit modifier appears, etc).
5.8.5
Alarm Inhibit (All Alarms) - by Point Quality
Point quality can be configured to cause all alarms to be inhibited/enabled when that particular quality flag is set/clear. For example, in a typical configuration, when a point is on test (point on test is set) all alarms for the point are inhibited. For an analogue point, the associated event and off-normal is also suppressed. The point quality alarm inhibit masks are configured, on a system basis, using the Database Configurator (in Common Data). When the point quality flag becomes set: Any current alarm indication is acknowledged and deleted: The alarm is acknowledged as described in Section 5.5.1. The alarm list entry is deleted. For analogue points, the associated Off-Normal List entry is deleted. Future point alarms: The alarm will be suppressed. For analogue points, the associated event will be suppressed. For analogue points, the associated off-normal will be suppressed. The point is flagged with that quality (e.g. the point is flagged point on test). An entry is made in the Administrative Tags List if appropriate (refer Section 2.6.4). An operator action event is generated if the flag was set by operator action.
When the point quality flag is cleared: Any currently suppressed alarm is re-annunciated as for a new alarm with the current date/time, unless suppressed for another reason. Future point alarms will be annunciated, unless suppressed for another reason. The quality flag is cleared from the point (e.g. the point on test flag is cleared). The related Administrative Tags List entry is deleted if there is one. An operator action event is generated if the flag was cleared by operator action.
5.9
Alarm Initialization
The Alarm and Off-Normal Lists only contain entries for currently existing conditions. When a station fails, the entries continue to be updated from backup stations, where available. Where redundant database stations are not available, any entries that originated from a failed station, prior to its failure, are removed. Alarms are initialized on station startup as follows. Points with access to redundant copies On station startup point alarms are synchronized from redundant copies. Thus the Alarm and OffNormal List that is generated on the station shows the same alarms as other stations.
5 Alarm Management
Points without access to redundant copies For points that do not have redundant copies, or if all stations are restarted, the points do not have access to redundant copies. Initially when the database is loaded: The alarm state of telemetered and calculated points is BAD, because the points have their initial status flag set. Points in an alarm condition (regardless of them having Bad Data status) will regenerate acknowledged alarms with their original annunciation time. There are two options, defined in a system startup file: 1. Generate an acknowledged alarm, with the original annunciation time, for all points that are in an alarm condition. Thus the Alarm List shows all current alarms. This is the default option. Points that have a configured annunciation delay generate an alarm without delay. 2. Generate alarms, with the original annunciation time, retaining the same acknowledge and delete status as before the shutdown. Thus the Alarm List entry is the same as before the shutdown. This includes points that were not in alarm, but still on the Alarm List before the shutdown. Events that would normally be generated with alarm annunciation are not generated during this alarm initialization. Off-normal conditions are re-established.
When telemetered and calculated points are first updated with live values: When telemetered and calculated points are first updated with live values (and the initial status flag is cleared), the alarm state is updated. Note that this update does not cause alarm annunciation if the alarm state is the same.
To ensure that there are no incorrect times in the future, the software checks if the original annunciation time exceeds the current system time. If the current system time is exceeded, then the current system time is used instead. Note that there is no similar check for events (events are not regenerated on startup). This condition is unlikely to occur because there are also time checks on the input processing (refer Section 4.2.4).
Page 138 of 215
6 Event Management
6
6.1
EVENT MANAGEMENT
Analogue Events
For analogue points, event generation is associated with alarm annunciation.
6.1.1

Events for Zone Alarms
For zone alarms, an event is generated: When an alarm is annunciated for the point entering and exiting high and low alarm. When an alarm is annunciated for the point changing alarm zones, for both worse (entering a higher zone number) and better (entering a lower zone number).
In the same way as for zone alarms, deadbands are taken into account.
6.1.2
Events for Flat Line Alarms
For flat line alarms, an event is generated: When an alarm is annunciated for the point entering, remaining in, and exiting the flat line condition.
6.2
Digital Events
Digital events can be generated for all types of digital points. Each point has an event state definition configured, to specify which point state changes are to generate an event. It can be when the point enters a given state, its normal state, or never, etc. Note: for digital points, event generation is not associated with alarm annunciation. For 2 and 4 state digital points, the Event State Definition can be any one of the following: No events. Event on change to State A. Event on change to State B. Event on change to State A or B. Event on change to off-normal state (not from off-normal to off-normal). Event on change to normal state. Event on change to normal state or to off-normal state (not from off-normal to off-normal). Event on all changes of digital state.
For multi-state digital points, the Event State Definition can be any one of the following: No events. Event on all changes of digital state.
Four state telemetered points, with some protocols, may generate an event from a transient state, when the field device changes from open to close (or close to open).
6.3
Events for Point Quality Alarms
Event generation for cause-alarm and suspend-alarm point quality flags is described in Section 5.3.
6.4
Events for Authorized Controls
Event generation for authorized controls is described in Section 5.4.1.
6.5
Events for Annunciation Time Delay
Event generation for annunciation time delay is described in Section 5.4.2.
Page 139 of 215
6 Event Management
6.6
Event Inhibit
Event inhibit suppresses point events. Events in the operators areas of responsibility can be inhibited manually by the operator, for the following: a) For a digital point: All events can be inhibited.
b) For an analogue point: All events can be inhibited. Better/worse events from alarm zone traversal (other than normal zone) can be inhibited.
Events can also be inhibited automatically depending on the condition of the point, as signified by the point quality.
6.6.1
Event Inhibit/Enable - All Events
For any point, all events can be inhibited/enabled via the Point Attributes Fascia. When all events are inhibited: Future point events will be suppressed. The point is flagged event inhibit. An entry is made in the Administrative Tags List. An operator action event is generated.
When the all event inhibit is removed: Future point events will be generated, unless suppressed for another reason. The event inhibit flag is cleared from the point. The related Administrative Tags List entry is deleted. An operator action event is generated.
6.6.2
Event Inhibit/Enable - Zone Events
For an analogue point, better/worse events from alarm zone traversal (other than normal zone) can be inhibited/enabled via the Point Limits Fascia. This inhibits events, from any zone except zone 0, to any other zone except zone 0, on the same side of normal zone. When zone events are inhibited: Future point zone events will be suppressed. The point is flagged zone event inhibit. An entry is made in the Administrative Tags List. An operator action event is generated.
When the zone event inhibit is removed: Future point zone events will be generated, unless suppressed for another reason. The zone event inhibit flag is cleared from the point. The related Administrative Tags List entry is deleted. An operator action event is generated.
6.6.3
Event Inhibit - by Point Quality
Point quality can be configured to cause event inhibit/enable when that particular quality flag is set/clear. For example, in a typical configuration, when a point is on test (point on test is set), all events for the point are inhibited/enabled. The point quality event inhibit masks are configured, on a system basis, using the Database Configurator (in Common Data). When the point quality flag becomes set:
6 Event Management
Future point events will be suppressed. The point is flagged with that quality (e.g. the point is flagged point on test). An entry is made in the Administrative Tags List if appropriate (refer Section 2.6.4). An operator action event is generated if the flag was set by operator action.
When the point quality flag is cleared: Future point events will be generated, unless suppressed for another reason. The quality flag is cleared from the point (e.g. the point on test flag is cleared). The related Administrative Tags List entry is deleted if there is one. An operator action event is generated if the flag was cleared by operator action.
6.7
Event Storage
Each HMI Station keeps a chronologically merged Event List on disc. All events for the current domain are stored in the same Event List. A typical system could hold 500,000 event records online, with older events accessible from archived files on DVD RAM. An event record corresponds to one line on the Event List Display, which may be the event message, event annotation or tag note. After an HMI Station is restarted, events that were generated during its outage are recovered from other HMI Stations. If all HMI Stations fail, then events that occur during this period of failure will be lost if they are not available in local holding buffers. The Event List consists of a number of separate time based online event files (e.g. 1 day). At the end of the time period the current online file becomes the previous online file, and the previous online file becomes the previous-1 online file, etc. The oldest online file is discarded. A new current online file is started. The previous-1 online file is made ready for archival to DVD RAM. The current and previous online files are duplicated on disc to ensure integrity after a station failure. New events are inserted in the current or previous online event file. Older events are discarded. The event file configuration is set by the following variables in a system startup file: Maximum time period covered by a file, from 1 hour to 7 days (default is 1 day). Number of online files to keep, from 3 with no particular limit (default is 8). Maximum number of event records in a file, from 100 with no particular limit (default is 100,000). Initial file capacity (default is 10000 records), and file resize increment (default is 10000 records).
The online files are mapped into memory and require the following size: number of online files x maximum number of event records x event record size (approx 136 bytes) Nominally each event file covers the configured time period, with the file sized according to the number of events it contains, up to the configured maximum number of event records in a single file. If the maximum is exceeded, a new current online file is started, and files are shuffled down similarly to end of time period processing. Thus there can be 2 (or more) files to cover the given time period, and the total time covered by all online files is reduced. Automatic Event File Archival Every hour (factory preset), event files that are ready for archival (i.e. over a day old), are stored on DVD RAM, if the correct disc is mounted. Refer to Section 2.10 for information on DVD RAM management. Event archive is dependent on having history archive running. The archived event files remain on disc. Every hour, the oldest files, archived or not, are deleted to limit the disc space used to a factory preset maximum (500MB). This includes files that have not been archived due to unavailable DVD RAM. Event archive activities are logged. Re-archival of files to DVD RAM (e.g. if a DVD RAM disc is damaged), is by manual copy using operating system commands. Users are responsible for maintaining proper operation of DVD RAM drive/disc (e.g. replacing full DVD RAM disc and remounting new one) to prevent any loss of archived events.
Page 141 of 215
7 Off-Normal Management
7
7.1
OFF-NORMAL MANAGEMENT
Analogue Off-Normals
For analogue points, off-normal generation is associated with the alarm condition.
7.1.1
Off-Normals for Zone Alarms
An off-normal is flagged when a point is outside the normal zone (i.e. outside zone 0). In the same way as for alarms, deadbands are taken into account.
7.1.2
Off-Normals for Flat Line Alarms
An off-normal is flagged when a point is in the flat line condition.
7.2
Digital Off-Normals
Digital off-normals can be generated for some types of digital points. The point has a normal state definition configured (can be changed online); to specify which point state is the normal state. All other point states are abnormal states. An off-normal is flagged when the points digital state is not in the configured normal state. If the point does not have a normal state, then it is never considered to be off-normal. Note: for digital points, off-normal generation is not associated with alarm annunciation. For 2 and 4 state digital points, the Normal State Definition can be any one of the following: State A. State B. No normal state defined.
For multi-state digital points there is no normal state, therefore off-normals are not generated.
7.3
Off-Normals for Point Quality Alarms
Off-normal generation for cause-alarm and suspend-alarm point quality flags is described in Section 5.3.
7.4
Off-Normals for Authorized Controls
Off-normal generation for authorized controls is described in Section 5.4.1.
7.5
Off-Normals for Annunciation Time Delay
Off-normal generation for annunciation time delay is described in Section 5.4.2.
7.6
Off-Normal Inhibit
Off-normal inhibit suppresses point off-normals. Any current off-normal is removed. Off-normals in the operators areas of responsibility can be inhibited manually by the operator, for the following: a) For a digital point: All off-normals can be inhibited.
b) For an analogue point: All off-normals can be inhibited.
Off-normals can also be inhibited automatically depending on the condition of the point, as signified by
7 Off-Normal Management
the point quality.
7.6.1
Off-Normal Inhibit/Enable - All Off-Normals
For any point, all off-normals can be inhibited/enabled via the Point Attributes Fascia. When all off-normals are inhibited: Any current Off-Normal List entry is deleted. Future point off-normals will be suppressed. The point is flagged off-normal inhibit. An entry is made in the Administrative Tags List. An operator action event is generated.
When the all off-normals inhibit is removed: Any currently suppressed off-normal is re-generated as for a new off-normal with the current date/time, unless suppressed for another reason. Future point off-normals will be generated, unless suppressed for another reason. The off-normal inhibit flag is cleared from the point. The related Administrative Tags List entry is deleted. An operator action event is generated.
7.6.2
Off-Normal Inhibit - by Point Quality
Point quality can be configured to cause off-normal inhibit/enable when that particular quality flag is set/clear. For example, in a typical configuration, when a point is on test (point on test is set), all offnormals for the point are inhibited/enabled. The point quality off-normal inhibit masks are configured, on a system basis, using the Database Configurator (in Common Data). When the point quality flag becomes set: Future point off-normals will be suppressed. The point is flagged with that quality (e.g. the point is flagged point on test). An entry is made in the Administrative Tags List if appropriate (refer Section 2.6.4). An operator action event is generated if the flag was set by operator action.
When the point quality flag is cleared: Future point off-normals will be generated, unless suppressed for another reason. The quality flag is cleared from the point (e.g. the point on test flag is cleared). The related Administrative Tags List entry is deleted if there is one. An operator action event is generated if the flag was cleared by operator action.
Page 143 of 215
8 Database and Supervisory
DATABASE AND SUPERVISORY
The database consists of object representations of real world items such as a circuit breaker, valve, transformer voltage, flow rate, RTU, communication channel; and also common data that describes the general characteristics of the whole system such as system constants, message texts, inhibit masks, quality mappings, and warmup information. The stored data serves many applications such as the HMI, History, Calculations and SQL Interface. Failover of objects does not need a station restart. The data is accessible globally, by applications in any station of the iSCADA System. Data access is across the network, where appropriate. Data persistency is maintained by periodic and change based uploads to disc. The Database Subsystem gets and stores data in realtime, from the referenced object/attribute wherever it may be in the distributed database, taking redundancy into account. The interface to this access is simple, with the actual data structure and location of data hidden from the user. Multiple clients can access the database concurrently. Change based processing facilitates larger systems, improves performance, and reduces data skew. The current standard product has HMI multi-domain support only.
8.1
Objects
An example of an object could be the Hornsby 11kV power transformer No 3 voltage. Typical object attributes are point name, point description, current value and quality, alarm limits, and scan address.
8.1.1
Object Description
Objects are added, modified and deleted using the Database Configurator. Some attributes are configurable (e.g. the alarm priority), and are presented via the Database Configurator. Some attributes are updated by the system (e.g. the alarm condition).
8.1.2

Object Name
The point name conventions are: Maximum of 25 printable ASCII characters. White space is allowed. Leading or trailing spaces, or multiple consecutive spaces are not allowed. These characters are not allowed: tab # ^ & @ ~ * ( ) { } [ ] = ; ` | \ / < > , . ? Must begin with an alphanumeric character (a-z, A-Z, 0-9). Names starting with a number, or having embedded spaces, are not recommended. These cause problems in calculation source code and the C50 RTU Configurator import/export. Names containing _ or % are not recommended. In SQL, these characters are wildcards, and require special treatment to retrieving point names containing _ or %.
Each point is configured with a unique name. Redundant copies (on other stations) have the same name (this is maintained automatically). Objects representing points also have a point description attribute. The point description conventions are: Maximum of 40 printable ASCII characters. White space is allowed. Tab is not allowed.
For object names, other than points, (eg channel, CLS, line, remote device, route, calculation task, calculation executable), there is a maximum of 16 printable ASCII characters. Refer to the Database Configurator Users Manual for further information.
8.1.3
Object/Attribute Identification (Pathname)
An attribute that is available for the user (e.g. when configuring displays, writing an application programs) to access is referenced by a pathname. The pathname includes the object name and the
attribute name. More details are presented in the following sections. An object or attribute is identified by its pathname, which can have two forms: Long Used to access a specific copy of the object (i.e. no redundancy). Short Normally used, allows redundancy by accessing the highest precedence copy of the object.
For full details refer to the iSCADA System HMI Engineers Manual.
8.2
Area, Alarm Group, Category, Alarm Priority
Database points are grouped by the following parameters. The parameters can be used in a variety of different ways, which is determined when the system is configured, by assigning each parameter value with a system wide meaning (e.g. area 23 means City South). Points are then configured with the desired parameter meaning (e.g. point abc belongs to City South). Area is typically related to the physical location of a point. Thus each point is assigned to one area. Each operator is assigned areas of responsibility, which the console uses when the operator logs on, to restrict the operator to only initiating functions on points that are assigned to their areas of responsibility. System lists are automatically filtered using the assigned areas as the filter mask. However, the operator can view displays of points in any area. An authorized user can alter the operators assigned areas of responsibility. A maximum of 64 areas are supported. Database points that do not have physical locations (e.g. calculated points) can be assigned to a logical area (e.g. calculated points for an AGC subsystem may be assigned to a logical area called AGC). Area 0 is reserved for internal (iSCADA) system alarms and events. An Alarm Group is a logical grouping of points that may be associated with a Control Window button (Section 2.4.3). More than one alarm group may be associated with a single button. System lists can be filtered by alarm groups. A maximum of 256 alarm groups are supported. Each point is assigned to alarm group, even if the point is not alarmable. Alarm Group 0 is reserved for internal (iSCADA) system alarms and events. Category allows points to be classified to suit user requirements. Category provides a convenient means of filtering required entries from system lists. A maximum of 64 categories are supported. A point may be assigned to any number of categories or none. Alarm Priority is used to determine the colour of an alarm line entry. Also, the audible alarm can be configured, so that the tone is determined by the alarm priority of the point (refer Section 2.4.6 Set Audible Alarm). Eight alarm priorities are provided, numbered 1 to 8, 1 is the highest, and the default is 8. If a user only needs (say) three alarm priorities then points need only be configured with priorities 1 to 3. Each point is assigned to alarm group, even if the point is not alarmable. User Definable Categories are provided. They can be defined during project definition. They are not runtime configurable. A maximum of four sets of user definable categories is provided. The sets of categories are independent of each other and each set is defined as a 64-bit mask (this is similar to category). User Definable Groups are provided. They can be defined during project definition. They are not runtime configurable. A maximum of four user definable groups is provided. The groups are independent of each other and each is defined as an integer value to a maximum of 1024 (similar to Area).
8.3
Persistence (Upload)
For objects that have redundant copies, software components that change the primary object normally propagate the change to the redundant copies of the object. Changes made to an object are uploaded to disc, allowing data to be retained through a station restart. Upload is performed periodically (every 5 seconds) and on a demand basis. Objects are uploaded in a
single operation.
8.4
8.4.1
Redundancy
Redundant Objects
Objects may have a maximum of three copies, although the standard system has been optimized for two copies. All instances of an object are located in different stations. The object name is the same for each instance of an object. Redundancy is provided at the object level. A particular station may be the primary station for a particular object, but the non-primary station for other objects. This supports failover at the object level. Each instance of an object has precedence assigned during configuration. The object with the highest precedence available is the current primary copy of the object. The precedence number is a number 1, 2, 3, etc (where 1 is the object with the highest precedence, 2 is the next highest precedence, etc). A different number is assigned to the copy in each physical station. Precedence can only be changed using the Database Configurator. Thus an object in a particular station keeps the same precedence. Referencing an object using the short path accesses the current primary copy of the object. When an object is written to, using its short path, the current primary copy of the object is updated.
8.4.2
Object Synchronisation
Software components normally keep the attributes of copies of an object in synchronisation with the attributes of the primary object. This includes telemetered values, calculation results, manual values, flags and tags, etc. Any operator actions on an object are also included, such as inhibit alarm, supervisory control, alarm acknowledge, alarm delete, etc. The attribute updates are performed on a change only basis. Synchronisation is used to recover from station or network failure. When a station is restored, its objects are updated from the current primary (most up to date) copies during the initialization procedure. Any objects in this station with a higher precedence, then become the current primary copies. If network faults cause non-connected SCADA islands to exist (which are later restored), the highest precedence object prevails as the current primary copy.
8.5
Networking
Supported network infrastructure is fast Ethernet, which must be redundant (in the current version). The recommended LAN bandwidth is a minimum of 100 Mbps. This does not preclude the use of lower speed networking (e.g. 10 Mbps Ethernet) at lower performances. When using TCP over Ethernet in a redundant configuration, two separate subnets are used; each is connected to all stations. The software in each station connects to all other stations using both subnets. Data traffic is distributed over both networks, with load balancing. If one network fails the system continues to operate on the other network. Warning " In the current version of the system, it has been reported that if both networks fail (causing islands), stations may abnormally terminate on reconnection.
8.6
8.6.1

Database Organization
Database Name
The database name conventions are: Maximum of 16 characters. Consists of any ASCII alphanumeric character, or: % _ - + !
Page 146 of 215
Note: space, tab, and / are not allowed. Must not begin with a digit or -.
8.6.2
Multiple Databases
Multiple databases can exist concurrently in the runtime environment. Only database processes with the same name communicate. Each database has its own object name space, therefore objects can be added, deleted and modified without affecting other databases. Typical databases are: A realtime database Running in the online system. Distributed. A development database The master copy of the realtime database, used off-line to configure changes (for subsequent installation into the realtime database). Nondistributed. A test database Used to test a database or system.
On each station, the Process Monitor keeps track of the status and location of the databases. A system display lists the available databases, showing the database name, status and server port address. Hardware resources limit the number of open databases. Though there is no software limit on the number of open databases in a workstation, too many reduces the performance of the workstation for realtime work. When the user opens a non-distributed database, the full database is served from the workstation where the database is kept. This requires memory and/or swap space resources to hold the database, and CPU resources to serve clients.
8.6.3
Database Distribution
The development database contains the objects for all stations. This database may be configured and installed as either: Non-distributed Distributed One single database residing on a single station. Non realtime databases, excluding history, cannot be distributed. Separate databases, with a subset of the total data set residing on different stations. A realtime database is distributed among the stations in the system. This distribution is done during database install.
8.7
Common Data
Common data describes the general characteristics of the system, which are defined using the Database Configurator. These are: Message texts, including alarm and event messages. System constants, including the number of alarm zones, and control reserve time out. Control and alarm inhibit masks and their mapping to quality flags. Object attributes to warmup during a database install. Message translation text keys, including areas, categories, state texts and alarm and event texts.
All stations configured with a database must possess common data. Refer to the iSCADA System HMI Engineers Manual for details.
8.7.1
System Constants
Typical system constants are: number of alarm zones, maximum alarm annunciation delay, automatic alarm acknowledgement time, tolerance factor for set points, and maximum valid past timestamp from RTU. System constants cannot be changed at runtime. Their configuration form in the Database Configurator is normally disabled. The iSCADA System Database Configurator Users Manual details how to enable this configuration form. The constants only take effect at initialization time. Therefore, a database restart must be done for
these to take effect.
8.7.2
Inhibit Mask for Point Quality Flags
The inhibit mask is a set of masks that specify the inhibit action resulting from the application of a database point quality flag (e.g. applying the point quality flag Operator Tag 1). This functionality is described in Section 2.5.1. A set of check boxes are used to configure inhibit masks for controls, alarms, events, and off-normals.
8.7.3
Class Warmup Attribute Lists
There is one warmup list for each object class that supports warmup. This includes all point classes. The user configures attributes that are to be warmed up for each list. The configuration form for warmup provides a pick list of classes that support warmup.
8.7.4
Message Translation of Text Keys
The system uses text keys to represent messages. The keys are translated into message text. The text corresponding to each key is user configurable. Messages are classified into types, which are used to facilitate Database Configurator help. For example, if a configuration screen requires the user to enter an engineering unit, it displays the list of all text messages of the engineering unit type. Refer to the iSCADA System Database Configurator Users Manual for details.
8.8
8.8.1
Supervisory
Process Monitor
The Process Monitor controls and monitors all the iSCADA processes on the station. It maintains a running log file of software operations and errors, for all iSCADA processes on that station. This includes database process start, normal and abnormal termination, and fatal errors.
8.8.2
System Time and Time Synchronisation
The iSCADA System time is based on Universal Coordinated Time (UTC). The user is presented with local time, which is UTC plus the local time zone information. Conversion is handled in time presentation and time entry. Stations in the system can be located in different time zones. Daylight saving time changes use a configuration file giving a list of dates, when local time changes are to occur. Again, these changes are handled in time presentation and time entry. The realtime clocks are not changed. Each processing unit is equipped with a realtime clock with battery backup. Stations within a domain are time synchronized to each other using Network Time Protocol (NTP), which is a distributed hierarchical client-server protocol, used to synchronize the clocks of stations in a subnet. The realtime clocks are not changed, except for any necessary small time corrections for clock drift. Typically, an external time source of a GPS, with TCP/IP input via the LAN, is used to provide accurate time synchronisation of the master station. If a CLS is present, a serial input of the GPS is used to provide accurate time synchronisation of the CLS. There is also an option, where one RTU can be nominated as the time master (instead of a GPS), to provide the external time source for synchronisation of the master station. Manual time changes are only necessary if there is no external time source. The new time is propagated to all other stations. Normally the system only needs small time changes. Time changes particularly in the backward direction should be kept small to minimize the effects on subsystems such as History.
Page 148 of 215
9 Calculations
CALCULATIONS
Calculation Programs are facilitated by the Calculations Configurator, Calculations Linker and Calculations Runtime. The Calculations Configurator provides a user interface that allows the definition, review, documentation and compilation of calculation programs. Alternatively, calculations can be prepared away from the system then imported into the Calculations Configurator. The Calculations Linker forms an executable module. It allows the user to link the calculation programs variables to database object attributes, and to specify the activation method and runtime priority. The Calculations Runtime Engine interprets the executable within the running system, accessing the database object attributes. Each executable may have a redundant backup in another station, which takes over if the primary fails. Period Type Calculations are described in Section 9.10, they are not related to Calculation Programs.
9.1
Calculation Programs
A calculation program describes a generic calculation or control function, such as the monitoring and control of a boiler. The program references variable names only known to the program. The calculation link phase produces an executable that can control a particular boiler, by linking the variables to the iSCADA System database points for that boiler. The same program can be linked many times to produce many executables. Calculation programs, can be initiated according to a periodic schedule, triggered by the change of state of a database point, or initiated on demand (e.g. by an operator pressing a pushbutton on a display). These methods of initiation can co-exist for a given program. The user may write as many separate programs as necessary to implement the calculations for the system. Calculations can be organized into programs in a way that best suits the user. This depends upon the activation methods for the various calculations, and how the user would like to logically group calculations, etc. A program consists of: External variables - used to input from and output to database point attributes. This may be to access variables used by the iSCADA System, or to achieve persistence from one executable run to the next. Local variables - used to provide a program with temporary storage, where persistence is not necessary from one executable run to the next. A local variable only has scope within the function or program it appears in. Calculations - expressions containing variables (such as analogue values, digital values), arithmetic operators, boolean operators, conditional operators, iterators, user-defined functions (Section 9.2.6) and built-in functions. Variable types include integer, real, array, structure, and user-defined types.
Programs are named as for variable names (Section 9.2.1.3), maximum length is 16 characters. An example program follows:
PROGRAM DENSITY (* Calculate density *) VAR_INPUT dens_at_T : REAL; END_VAR VAR_IN_OUT corr_dens : REAL; END_VAR VAR SG1_MS_15, SG2_MS_15, SG1_SKO_15, SG2_SKO_15, SG1_HSD_15, SG2_HSD_15 : REAL; dummy : SINT; END_VAR IF (_USINT_0 = 0) THEN dummy := QualityClear(corr_dens,28); (* calc bad first time *) _USINT_0 := 1; END_IF; SG1_MS_15 := 0.66; SG1_MS_T := SG1_MS_15 / exp(-(15.0-T)*Bms);
9 Calculations
IF (SG1_MS_T <= SG_at_T <= SG2_MS_T) THEN . . . END_IF; END_PROGRAM
9.2
9.2.1
9.2.1.1
Language Elements
Use of Characters
The Basic Line
The basic usage of lines and characters is as follows: Blank lines are ignored. Additional spaces are ignored. A given statement can run on from one line to the next (i.e. carriage returns are ignored). Statements can be contained on the same line, e.g.: VAR x:REAL; y:REAL; END_VAR IF x>0.5 THEN x:=1.0; ELSE x:=0.0; END_IF; Multiple statements can continue on from each other on the same line. Spaces are optional, where omitting them does not cause the statement meaning to change, e.g.: temp : REAL; temp:REAL; IF count > 5 THEN IF count>5 THEN IFcount > 5 THEN IF count > 5THEN is recommended. is okay. is recommended. is okay. is not okay. is not okay.
x := (temp1 + temp2 + temp3) / 3; is recommended. x:=(temp1+temp2+temp3)/3; is okay. VAR x:REAL; END_VAR VARx:REAL; END_VAR is okay. is not okay.
Case is sensitive, e.g. TEMP and temp are different names, and var is not a valid keyword for VAR. Keywords
9.2.1.2
Keywords are unique character strings used in the language syntax (e.g. VAR, IF, THEN, EXIT). 9.2.1.3 Variable Names
The rules for variable names are: Consists of a string of letters A to Z, letters a to z, digits 0 to 9, and underline characters _. Begins with either a letter or underline character. Multiple adjacent underline characters are not allowed. Embedded spaces are not allowed. Keywords are not allowed. At least 32 characters of uniqueness is provided.
Typical examples are TEMP, TEMP25, TEMP_SECS, _Main6_Valve99, Boiler_5_Valve_173c. 9.2.1.4 Comments
Comments are delimited at the beginning by (*, and at the end by *). They are permitted wherever
9 Calculations
spaces are allowed, except in character string literals. Comments cannot be nested.
9.2.2
Literals
Signed decimal integers: Consist of a plus (optional) or minus sign, followed by digits 0 to 9. An optional underline character can be inserted (this is ignored, it is for user information only). For example, 12345, -628, 0, +12, 385_29. Binary integers: Consist of 2#, followed by digits 0 or 1. An optional underline character can be inserted (this is ignored, it is for user information only). For example, 2#01101111, 2#1001_1011. Octal integers: Consist of 8#, followed by digits 0 to 7. An optional underline character can be inserted (this is ignored, it is for user information only). For example, 8#377, 8#14_70. Hexadecimal integers: Consist of 16#, followed by digits 0 to 9, and letters A to F or a to f. An optional underline character can be inserted (this is ignored, it is for user information only). For example, 16#FFF0FF00, 16#12acfbao, 16#12AD_FFCB. Real numbers: Consist of a plus (optional) or minus sign, followed by any number of digits 0 to 9 with a compulsory decimal point, and optional exponent of E (or e) with signed decimal integer. For example, 12345.0, -628.0, 0.0, +12.0, 1.0E5, 1.234E-6, -0.16754E+8, 1.0e20. Booleans: Consist of keywords FALSE and TRUE. Strings: Consist of a string of up to 80 unsigned bytes, framed with a pair of single quote characters. Parenthesis ( and ) are not allowed. Parenthesis and non-printable characters can be inserted by prefixing the hexadecimal value with a $. Special characters can be inserted as follows: Code $$ $ $L or $l $N or $n $P or $p $R or $r $T or $t Interpretation Single dollar sign Single quote character A line feed character A new line character Form feed, new page Carriage return character Tab character
9.2.3
9.2.3.1
Data Types
Elementary Data Types
Integer Data Types: Any decimal, binary, octal or hexadecimal integer can be assigned. SINT INT DINT LINT USINT UINT UDINT ULINT Short Integer (8 bit) (range: -128 to +127) Integer (16 bit) (range: -32768 to +32767) Double Integer (32 bit) (range: -2147483648 to +2147483647) Long Integer (64 bit) (range: -9223372036854775808 to +9223372036854775807) Unsigned Short Integer (8 bit) (range: 0 to +255) Unsigned Integer (16 bit) (range: 0 to +65535) Unsigned Double Integer (32 bit) (range: 0 to +4294967295) Unsigned Long Integer (64 bit) (range: 0 to +18446744073709551615)
Bit String Data Types: Any binary, octal or hexadecimal integer can be assigned. BYTE WORD DWORD LWORD Bit string of length 8 (8 bit) (range: 0 to 16#FF) Bit string of length 16 (16 bit) (range: 0 to 16#FFFF) Bit string of length 32 (32 bit) (range: 0 to 16#FFFFFFFF) Bit string of length 64 (64 bit) (range: 0 to 16#FFFFFFFFFFFFFFFF)
Real Data Types: Any real can be assigned. REAL LREAL Real number (32 bit), IEEE single precision (minimum positive normal number is 1.17549435e-38, maximum normal number is 3.40282347e+38). Long real (64 bit), IEEE double precision (minimum positive normal number is 2.2250738585072014e-308, maximum normal number is 1.7976931348623157e+308).
Page 151 of 215
9 Calculations
Boolean Data Type: Any boolean can be assigned. BOOL Boolean (FALSE or TRUE)
String Data Type: Any string can be assigned. STRING 9.2.3.2 String of unsigned bytes (range: 0 to 80 characters, see string literal). User Defined Data Types
The user may define data types. They are named as for variable names, except the maximum length is 16 characters. They are available for use by programs, functions and other user defined data types, just like elementary data types. There is no fixed limit to the nesting of type definitions but it is recommended not to exceed 5 levels, in order to minimize effect on performance. A data type declaration cannot include itself, either directly, or indirectly, at lower nested levels. If a user defined data type is modified, all programs and functions that call it (directly or indirectly), must be re-compiled by the user. Direct Derivation Data Type: An elementary or user defined data type can be assigned another name: TYPE POWER : REAL; END_TYPE VAR GeneratorPower : POWER; END_VAR GeneratorPower := 234.5; Enumerated Data Type: Specifies that variables of that type, can only take on one of the named values in the list (each named value has a specific value assigned internally by the compiler): TYPE FruitClass : (Apple, Pear, Orange); END_TYPE VAR Fruit : FruitClass; END_VAR Fruit := Apple; Array Data Type: An array can have up to 5 dimensions of either an elementary or user defined data type. The array is indexed by an integer literal or variable (negative is allowed): TYPE ParameterArray : ARRAY [1..16, 0..100, 50..59, -20..20] OF REAL; END_TYPE VAR Parameter : ParameterArray; END_VAR Parameter[4, 0, 55, -10] := 25.534; Structure Data Type: Structures consist of any combination of elementary and user defined data types (including other structures). Array data types can be declared in the structure: TYPE STRUCT_1 : STRUCT E1 : INT; E2 : STRING; E3 : MYARRAY; E4 : ENUM_1; E5 : ARRAY_1; E6 : STRUCT_2;
(* Structure Name *) (* An Elementary Type*) (* (* (* (* A A A A user-Direct Derivation Type *) user-Enumerated Type *) user-Array Type *) user-Structure Type *)
Page 152 of 215
9 Calculations
E7 : ARRAY E8 : ARRAY E9 : ARRAY E10: ARRAY E11: ARRAY END_STRUCT; END_TYPE TYPE STRUCT_2 : STRUCT ELEMENT_A ELEMENT_B ELEMENT_C ELEMENT_D END_STRUCT; END_TYPE
[1..16] [1..16] [1..16] [1..16] [1..16]
OF OF OF OF OF
INT; MYARRAY; ENUM_1; ARRAY_1; STRUCT_2;
(* Array Declarations *)
(* 2nd Structure Name *) : : : : REAL; MYARRAY; ARRAY_1; ARRAY [1..16] OF ARRAY_1;
VAR RECORD : STRUCT_1; END_VAR
(* Variable Declaration *)
RECORD.E1 := 25; (* Variable references *) RECORD.E2 := Some Text; RECORD.E3[8] := -140; RECORD.E6.ELEMENT_A := 145.64; RECORD.E6.ELEMENT_C[4] := 73; RECORD.E6.ELEMENT_D[2][7] := 64; RECORD.E10[7][12] := 0; RECORD.E11[6].ELEMENT_C[8] := 200;
9.2.4
Variable Definitions and SCADA Database Interface
Variables are declared in programs and functions, using variable and a data type names, for example: VAR x : REAL; a, b, c : INT; END_VAR The scope of a variable may be local or external (i.e. the variable accesses a database point attribute), according to the type of VAR statement used. Note that for the current software implementation, a program must have at least one external variable defined. Quality flags are discussed in Section 9.7.5. Local Variable (VAR): External Read only Variable (VAR_INPUT): There is no input from or output to the database. Variables are only input from the database.
External Read/Write Variable (VAR_IN_OUT): Variables are input from and output to the database. External Write Only Variable (VAR_OUTPUT): VAR_OUTPUT is treated the same as VAR_IN_OUT (thus when the variable is stored in the database, it has at least the original value in it). Output can only be to calculated database point types. With the exception that for telemetered and manual point types the software tags only are output. Refer Section 9.7.3. References to external variables are limited to elementary (or direct derivation elementary) data types: REAL for the current value and quality (cvq), high limit, etc, of analogue and accumulator points. USINT for the current status and quality (cvq) of digital points. Corresponding data type for other attributes.
All VAR_IN_OUT and VAR_OUTPUT variables should be assigned a value, on each executable run. This ensures that if a variable had a calculation error quality flag set on some previous run, then it will now be cleared. Where possible use VAR_INPUT variables. Alternatively, the calculation error quality
9 Calculations
flag can be cleared using the QualityClear function. Warning " All VAR variables must be assigned a value before being referenced. It has been reported that the current version of the system may abnormally terminate if this condition is not met.
9.2.5

Statements
General rules for all statements are: Variables can only be single element (e.g. cannot reference a whole array). Data types must be consistent at all stages of expression evaluation, comparisons, result storage, etc (i.e. type casting is not automatic). Functions are provided for the user to perform type conversion, where necessary. A statement can be empty (i.e. a ; only). A function call (e.g. QualitySet(x, 44);) cannot be used on its own as a statement (even though it may not return a value), it must at least be put in an assignment statement. Assignment Statement
9.2.5.1
The assignment statement evaluates the expression and stores the result into the variable. Type STRING is supported. y := <expression>; Typical examples are: y := (TEMP + 250.0) / K_FACTOR; StringA := StringB + StringC + another string of chars $n; Where: StringA, StringB and StringC are of type STRING. 9.2.5.2 IF Statement
If the boolean expression is true the true statement list is executed, if false the false statement list is executed. ELSE is optional. Any statement list can be omitted. IF <boolean expression> THEN <true statement list> ELSE <false statement list> END_IF; ELSIF can be used as follows: IF <boolean expression1> THEN <true1 statement list> ELSIF <boolean expression2> THEN <true2 statement list> ELSE <false2 statement list> END_IF; 9.2.5.3 CASE Statement
The integer expression is evaluated, resulting in a signed selection integer. The statement list for the first matching case is executed. If no match is found the ELSE statement list is executed. ELSE is optional. Any statement list can be omitted (causing no action for that case). CASE <integer expression> OF 3 : <statement list> 4, 1 : <statement list>
9 Calculations
7..9, -2 : <statement list> ELSE <statement list> END_CASE; 9.2.5.4 FOR Statement
The FOR statement repeatedly executes the statement list with the control variable x starting at from, incrementing by increment, until (and including) to is reached. The from, to, and increment are signed integer expressions. If BY is omitted then the increment is +1. The value of the control variable after loop termination is undefined. The control variable, from, to, and increment values cannot be changed in the statement list. FOR x := <from> TO <to> BY <increment> DO <statement list> END_FOR; The EXIT statement can be used to terminate iterations before the termination condition is satisfied. With nested FOR loops, the current loop is terminated, returning control to the next level up. FOR x := <from> TO <to> BY <increment> DO <statement list> IF <boolean expression> THEN EXIT; END_IF; <statement list> END_FOR; 9.2.5.5 WHILE Statement
The WHILE statement repeatedly executes the statement list while the boolean expression is true. The test for the termination condition is made at the beginning of each iteration. If the boolean expression is initially false then the statement list is not executed at all. WHILE <boolean expression> DO <statement list> END_WHILE; The EXIT statement can be used to terminate iterations before the termination condition is satisfied. With nested FOR loops, the current loop is terminated, returning control to the next level up. 9.2.5.6 REPEAT Statement
The REPEAT statement repeatedly executes the statement list until the boolean expression is true. The test for the termination condition is made at the end of each iteration. The statement list is always executed at least once. REPEAT <statement list> UNTIL <boolean expression> END_REPEAT; The EXIT statement can be used to terminate iterations before the termination condition is satisfied. With nested FOR loops, the current loop is terminated, returning control to the next level up. 9.2.5.7 Expressions
An expression is composed of operands and operators. It can consist of a single operand, or be complex involving many levels of nesting with the use of parenthesis. An operand can be a literal, a variable, or a function call. If an operand is used in an expression before the operand is initialized, the result will be bad quality. The following operators are available. Operators are applied in precedence order from high to low. Operators of equal precedence are applied as written in the expression, from right to left. Precedence 1 (high) Symbol () Operation Parenthesis Comment
Page 155 of 215
9 Calculations
2 3 4 5
6 7
9 Boolean expression 10 Boolean expression 11 Boolean expression 12 Bitwise (integer, bit string) 13 (low) Bitwise (integer, bit string) Notes: 1) For ULINT, the result range is limited to LINT positive range. 2) If the first operand is negative (y := -x**n), negation has a higher precedence than exponentiation. The only operator supported for type STRING is +. This operation appends the string (e.g. StringA := abc + def + ghi; gives result abcdefghi.
fn( ) ** NOT * / MOD + < > <= >= = <> AND XOR OR | &
Function call Exponentiation (power) Negation Boolean complement Multiply Divide Modulo (remainder of divide) Add Subtract Less than Greater than Less than or equal to Greater than or equal to Equal Not equal Logical AND Logical exclusive OR Logical OR Logical OR Logical AND
See notes 1 & 2 below. Boolean expression Integers round down Integer types only
9.2.6
User Defined Functions
The user may define functions. They are named as for variable names, except the maximum length is 16 characters. They are available for use by programs and other user defined functions, just like builtin functions. They can be called with a number of parameters, and return a single variable. A function is inherently re-entrant. It can call itself any number of times (however, the user must be aware that the amount of storage space used is a limitation). Local variables are created for each entry of the function, therefore changing a local variable has no effect on the same named variable at another level of call. Functions are defined similarly to programs, except: They have local variables only. However, the function call can pass external input variables as parameters. The functions return value can be stored into an external output variable. The functions input parameters are defined by a VAR_INPUT statement of elementary data type. The return variable name within the function is the function name, of elementary data type stated.
If the interface to a user defined data type is modified, all programs and functions that call it (directly or indirectly), must be re-compiled by the user. FUNCTION AVG_TEMP : REAL (* Function name and type of return value *) VAR_INPUT (* Functions input parameters *) TEMP1, TEMP2, TEMP3 : REAL; END_VAR VAR (* Local variables *) x : REAL; END_VAR AVG_TEMP := 0.0; (* Init Result *) x := (TEMP1 + TEMP2 + TEMP3) / 3.0; (* Calculate average *) IF x > 100.0 THEN (* If in range *) AVG_TEMP := x; (* Return average *) ELSE AVG_TEMP := 100.0; (* Else return minimum *) END_IF;
9 Calculations
END_FUNCTION The function is called by: AVG_TEMP(Point1,Point2,Point3)
9.3
Built-in Functions
The following table shows the built-in functions that are provided. The user cannot alter them. Functions that do not return a result can be called anywhere in an expression, or called by (for example): dum := QualitySet(x, FLAG) Where: dum is a dummy variable (type INT). Function Operation Note TYPE1_TO_TYPE2(any) Convert elementary data type TYPE1 to TYPE2, e.g. INT_TO_REAL(i), REAL_TO_STRING(y). Where i is an integer type and y is a real type. 1 TRUNC(x) Truncate x (REAL or LREAL) towards 0, result is type LINT 2 sin(x) sine of x (radians) (2 radians = 360) 3 cos(x) cosine of x (radians) 3 tan(x) tangent of x (radians) 3 asin(x) arc sine (range -/2 to /2) of x 3 acos(x) arc cosine (range 0 to ) of x 3 atan(x) arc tangent (range -/2 to /2) of x 3 exp(x) e**x 3 log(x) natural logarithm of x 3 log10(x) base 10 logarithm of x 3 abs(x) Absolute value of x 3 sqrt(x) Square root of x, correctly rounded 3 QualityClear(x, FLAG) Clear quality FLAG of variable x 4 QualitySet(x, FLAG) Set quality FLAG of variable x 4 QualityTest(x, FLAG) Test quality FLAG of variable x 4 CMP(StringA, StringB) Compare two strings (case-sensitive). Result = 0, if equal. Result > 0 or < 0, according to the sign of the difference between the values of the first pair of bytes that differ. Result is type INT. LEN(StringA) Return the number of bytes in a string (not including the null terminator). Result is type INT. System Functions: [Generate an alarm] Setting a database point value into an alarm condition raises an alarm. There is no specific function to generate an alarm. SAbort(abortCode) Abort program execution, without storing any outputs. The abortCode (DINT) is logged in the Process Monitor log file. No result is returned. diag(REF, x) Output a diagnostic message to the Process Monitor log file. REF (type UDINT) is typically a user specified reference number, to locate the message generation in the source code. x (type LREAL) is any value. No result is returned. For example, diag(11025, x), with x = 753.812, will print: INFO: Calculation: Diagnostic message reference line is: 11025 parameter value is 753.812. SDemand(exeName) Activate an executable exeName (type STRING) (must be demandable). The executable will execute immediately if it has a higher priority. The result (type INT) is an error code (0 = no error, 1 = not ready, 2 = does not exist, 3 = error occurred). SDelay(t) Delay program execution for a specified time t (type UDINT, seconds). When the delay expires, the program resumes at the next statement. No result is returned. STimeSeconds(dum) Return the current time in seconds (number of seconds since 00:00:00 UTC on January 1, 1970. Result is type UDINT. STimeCalendar(time_cal Return the current local date/time into time_calendar. This is similar to the endar) localtime UNIX command. 5
9 Calculations
SExeAlarm(dum)
Change the state of the executables alarm point, to generate an alarm to alert the operator that attention is required. The state of the executable alarm point is changed to ON (=1) or OFF. No result is returned. SEvent(eventMessage) Generates an event consisting of the program name (16 characters) and the eventMessage string parameter. eventMessage is a maximum of 61 characters (any longer is truncated). The event type is calc-event (currently magenta colour). No result is returned. SRefresh(pid1) Refresh program variable pid1 (type STRING) from its database point (there is no output to the database). Can only be used in programs (not functions). The result (type INT) is an error code (0 = no error, 1 = error). SRefreshIn(dum) Refresh all VAR_INPUT variables from their database points. Can only be used in programs (not functions). The result (type INT) is an error code (0 = no error, 1 = some errors). Error code 1 means one or more variables have a refresh error. For variables that do not have an error, they are refreshed. For variables that have an error, their values remain unchanged. SRefreshInOut(dum) Refresh all VAR_IN_OUT variables from their database points (there is no output to the database). Can only be used in programs (not functions). The result is as described for SRefreshIn. SRefreshAll(dum) Refresh all VAR_INPUT, VAR_IN_OUT and VAR_OUTPUT variables from their database points (there is no output to the database). Can only be used in programs (not functions). The result is as described for SRefreshIn. SWrite(pid1) Write the variable pid1 (type STRING) to its database point now. The result (type INT) is an error code (0 = no error, 1 = error). SWriteOutput(dum) Write all VAR_OUTPUT variables to their database points now. The result (type INT) is an error code (0 = no error, 1 = some errors). Error code 1 means one or more variables have a write error. For variables that do not have an error, they are written. For variables that have an error, their values are not written. SWriteInOut(dum) Write all VAR_IN_OUT variables to their database points now. The result is as described for SWriteOutput. SWriteAll(dum) Write all VAR_IN_OUT and VAR_OUTPUT variables to their database points now. The result is as described for SWriteOutput. Control Functions (refer Section 9.3.1): requestID := Create a control request. With priority (type USINT) (refer Section 2.4). The SCreateCtrlReq(priority, resume option resumeOpt (type INT, must be = 1). The program resumes resumeOpt) after all controls are sent and RTU acknowledgments received. The returned requestID (type UDINT) is a unique number which identifies the request. If requestID = 0, then it failed to get a free control request. SAddPointCtrl(requestID, Add a control point point (type PointInfo) to control request requestID. point) The result is an error code (type DINT): 0 = no errors, 1 = invalid request ID, < 0 = failed to add control point. SAddPointVarCtrl(reques Add a control point that is linked to variable variableName (type STRING), tID, point, variableName) to control request. The variable variableName can be in a VAR_INPUT, VAR_IN_OUT or VAR_OUTPUT, but not a parameter of a function. This function allows the control point name to be supplied at link time. The result is an error code (type DINT): 0 = no errors, 1 = invalid request ID, 2 = variableName does not exist, < 0 = failed to add control point. SGetPointId(variableNam Get the Point name (as type STRING) that is linked to variable e) variableName. The variable can be in a VAR_INPUT, VAR_IN_OUT or VAR_OUTPUT, but not a parameter of a function. If the variableName does not exist, an empty string is returned. SInitiateCtrl(requestID) Execute the control request requestID. The result is an error code (type DINT): 0 = no errors, 1 = invalid request ID, 2 = some point controls failed. SReleaseCtrlReq(reques Release the control request requestID. tID) The result is an error code (type DINT): 0 = no errors, 1 = invalid request ID. Sequence Control Functions (refer Section 9.4):
9 Calculations
SNewCommand(dum)
SResumeStep(dum) SClearStepHistory(dum) SSetStepHistory(idx, value)
Read in a new sequence control command initiated by the operator. The result is a command code: 0 = no new command, 1 = Pause command, 2 = Resume command, 3 = Abort command. Read in the step number from the Resume From Step field. The returned step number includes zero, if entered in field. Clear the step history values. No result is returned. Set value (type USINT) in step history number idx (type UINT). No result is returned.
1. Conversion of LREAL to any other type, is accurate to 15 fractional digits. Conversion of REAL to any other type, is accurate to 6 fractional digits. Conversion of real to integer types, round correctly, as per the rint( ) rounding function. Conversion of signed to unsigned types, drop the sign, i.e. -123 becomes 123. For conversion of large to smaller types, the most significant bits (not digits) are dropped. Conversion of STRING to any other type, accepts signed decimal integer and real numbers (eg it does not accept other integers of the form 16#F0EA, or boolean TRUE, etc). 2. If the value is too large to fit, the most significant bits (not digits) are dropped. 3. x can be any real or integer type. The result can be used as any real or integer type. 4. FLAG (type UDINT) is the point quality flag number (refer Section 4.3.1). QualityTest operates on all point quality flags. QualityClear and QualitySet only operate on Calculation Error and Software Tags 1-8. 5. time_calendar must have a user defined data type (e.g. TM_STRUCT) as follows: TYPE TM_STRUCT : STRUCT Sec : DINT; Min : DINT; Hour : DINT; Mday : DINT; Mon : DINT; Year : DINT; Wday : DINT; Yday : DINT; Isdst : DINT; (* Local Date/Time *) (* (* (* (* (* (* (* (* (* (* (* (* Seconds (0-59) *) Minutes (0-59) *) Hours (0-23) *) Day of Month (1-31) *) Months since January (0-11) *) Years since 1900 *) Days since Sunday (0-6) *) Days since January 1 (0-365) *) flag for daylight savings time *) >0 if daylight savings time *) =0 if not daylight savings time *) <0 if daylight savings time *)
END_STRUCT; END_TYPE
9.3.1
Control Functions
Each call can handle more than one supervisory control. However, only one control action is allowed to be in progress per RTU. Concurrent controls on different RTUs are permitted. Control reserve and unreserve are performed automatically. Controls use the standard two pass action, with check before operate sequence, feedback monitoring, and demand scan. Refer Section 9.4.4 for example usage. The calling program is suspended, when the control request is executed. It is resumed after all controls have been sent to the RTUs, and control request/execute acknowledgments have been received from the RTUs. A status is returned for each control point in ErrorCode. The structure point contains the point control information. The structure is type PointInfo that must be defined as follows (i.e. a user defined data type): TYPE PointInfo : STRUCT PointName : STRING; CtrlOperation : USINT;
(* Point control information *) (* Point name *) (* Control operation *)

Page 159 of 215
9 Calculations
CtrlParameter : REAL; ErrorCode : DINT; END_STRUCT; END_TYPE Where: PointName is the control point name.
(* Control parameter *) (* Error code *)
The control operation CtrlOperation and control parameter CtrlParameter are as below. ErrorCode is the error code returned by the control function or underlining control software. Control Operation Trip open Trip close Momentary raise Momentary lower Scaled raise Scaled lower Setpoint CtrlOperation 1 2 3 4 5 6 7 CtrlParameter Not applicable Not applicable Not applicable Not applicable Raise increment 0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0 or 7.0 Lower increment 0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0 or 7.0 Setpoint value (in engineering units) (e.g. 56.28)
9.4
9.4.1
Sequence Control Facilities

Sequence Control Program
A control sequence is implemented, by writing a calculation program that executes a number of supervisory controls in a predefined sequence. A sequence consists of a number of steps. In each step, there is a set of actions to be taken. This may be arithmetic calculations and/or supervisory controls. Transition from one step to another step is determined by the sequence program (e.g. depending on the state of a set of field inputs, as requested by the operator, etc). The operator interface to a sequence control program is via the Sequence Display for viewing the sequence status, and the Sequence Control Fascia that allows the sequence to be controlled. The basic sequence control program framework given in Section 9.4.4 can be used, together with sequence control functions (Section 9.3) and internal data elements (Section 9.4.3). Typical actions are: Read operator commands (pause, resume, abort), via function SNewCommand, and take action. Read a new step number, via function SResumeStep, and proceed to that step. Write to internal data elements, including current sequence state, step number and message. Perform controls and calculations, check control actions, delays and generate events. After a control is initiated, the program can monitor for completion by repeatedly refreshing input variables from the field. When conditions are met, the program can update the step variable and move on to the next step. If an abnormal condition is detected, the program may take recovery steps or terminate the sequence. The monitoring of the control commands is done within the control function if the resume option is set to 3. Appropriate actions must still be taken if an error is returned. When a step has encountered an error, or requires operator confirmation, the program stores an operator message, changes the executables alarm point with the SExeAlarm function, and pauses the sequence. The operator can skip the step, or retry it by resuming at that step number.
9.4.2
9.4.2.1
Operator Interface
Sequence Display
The Sequence Display allows a sequence to be monitored. The user configures this. A standard display is supplied with the system. The program maintains most indications.
Page 160 of 215
9 Calculations
Executable Name: Boiler_Start Description: Startup Boiler No 1
Overall Elapse Time:
00 : 02 :47
Sequence State:
IN PROGRESS ENABLED
Current Step Elapse Time: 00 : 00 :15

1 Close discharge damper 2 Close fan vanes Open fan brake 3 Turn on oil pump 4
Turn on jacking oil pump
5 Close AC circuit breaker
6 Close discharge damper
7 Turn on vane auto control
8 Sequence complete
Message: Step 3: Turn on oil pump
Step boxes show the progress of the sequence (_Step_History_<step number>). The sequence program maintains them. Each box represents a step. The box colour (user configurable) indicates the status of the step, for example: White (=0) - the step is yet to be executed. At the start of the sequence all boxes are white. Green (=1) - the step has completed successfully. Yellow (=2) - this step is the current step. Red (=3) - the step has failed. Operator message - displays a text message output by the sequence control program (_Operator_Message). Typically, it requests operator confirmation when the sequence reaches a critical step or has encountered errors in a step. Sequence state - shows the current state of the sequence (_Sequence_State). Also, the Sequence Control Fascia can be invoked by selecting this field. Enable/Disable - shows whether the sequence control program is enabled or disabled (_Exe_Enable). Selecting the field toggles this (only effective before a Start). Overall elapse time - displays the elapsed time from sequence start to the current time (_Overall_Elapse). The timer is reset by program initialization and incremented every second by the Calculation Runtime. If the elapsed time is greater than a day, the time will remain at 23:59:59. Step elapse time - displays the elapsed time from the current step start to the current time (_Step_Elapse). The timer is reset by the program when it starts a new step, and incremented every second by the Calculation Runtime. Sequence Control Fascia
9.4.2.2
The Sequence Control Fascia allows a sequence to be controlled. A standard fascia is supplied with the system. An operator action event is generated whenever a sequence is started, paused, resumed or aborted by the operator. The Calculations Runtime starts a sequence, but the pause, resume and abort commands are handled by the sequence control program. There can be a delay in response to the command, because the sequence program only checks for operator commands periodically. If multiple commands are issued before the sequence program examines the command, the last command prevails.
Page 161 of 215
9 Calculations
Executable Name: Boiler_Start Description: Startup Boiler No 1
Database: realtime1
Step Mode OFF
Resume From Step:
1 (0 for current step)
START
PAUSE
RESUME
ABORT
Enter
Reset
Cancel
Step Mode - shows whether the sequence control program is in single step mode (_Step_Mode). Selecting the field toggles this. The program should check this status before the start of each step, and automatically pause itself if in single step mode. The program can then be switched in/out of single step mode at any time through the sequence. Start Button followed by Enter initiates the program from its beginning. The sequence starts at the step determined by the program (normally step 1). A step number cannot be entered from the fascia. The button is only sensitive when the sequence is in the idle state. Pause Button followed by Enter normally pauses the program before the next step. The program decides what action to take, when the function SNewCommand returns the pause code. The button is only sensitive when the sequence is in the run state. The operator resumes the sequence. Resume Button followed by Enter normally resumes the program at the next step. The program decides what action to take, when the function SNewCommand returns the resume code. The program continually checks for this, and resumes the sequence from the current step (Resume From Step). This may be the next step in the sequence, or it can be a step number entered by the operator. The button is only sensitive when the sequence is in the pause state. Abort Button followed by Enter normally aborts the program before the next step. The program decides what action to take, when the function SNewCommand returns the abort code. The button is only sensitive when the sequence is in the run or pause state. Resume From Step - shows the current step number (_Current_Step). The program updates this. The operator can type in a step number, which is returned by function SResumeStep and validated by the program. The program is normally coded so that zero runs the current step.
9.4.3
Program Interface - Internal Data Elements
Each executable has several internal data elements. These are used for controlling program execution and to provide a general purpose storage area for program use. This local data is retained between program runs, but is lost if the database is restarted. Local data variables are created and initialized to zero (or the null string) at system initialization. After initialization, redundant executables are kept synchronized with the primary program (except for the variables _Exe_Name, _Exe_Description, and _Exe_State). Internal data elements are displayable and modifiable by the HMI Subsystem. A program can store a value in the user data area for use in the next run. This avoids having database points to hold the value. The value is accessible directly from the program and functions without the overhead of database read/write calls. At each second, if local data variables have been changed, the new values are published. If no variable has been changed, publish will not occur. This is to avoid unnecessary CPU load. The following data elements are provided. The user need not be too concerned if using the basic sequence control program. Attempts to assign a value to a Read Only element are rejected by the Calculation Compiler. The name of each internal data element is prefixed by _. Executable Name (_Exe_Name) (STRING) (Read Only)
Page 162 of 215
9 Calculations
Executable Description (_Exe_Description) (STRING) (Read Only) Executable State (_Exe_State) (USINT) (Read Only) Holds the current state of the executable. The Calculation Runtime sets the state: 0 = Idle enabled - executable is idle and enabled. 1 = Idle disabled - executable is idle and disabled. 2 = Squelch - executable is in squelch period (refer Section 9.6.1.6). 3 = Non-recoverable error - executable has encountered a non-recoverable error. It will not be run. 4 = I/O wait - executable is in I/O wait state (e.g. control is in progress). 5 = Delay - executable is in delay state. 6 = Ready - executable is in the ready queue (either executing or waiting to execute).
Primary Executable State (_Main_Exe_State) (USINT) (Read Only) This is similar to _Exe_State, but it is the state of the primary executable instead of the current executable (which could be the backup executable).
Sequence State (_Sequence_State) (USINT) Holds the current state of a sequence: 0 = Idle - sequence is in idle state. Set by the program. Also set by the Calculation Runtime at system initialization time. 1 = In Progress - sequence has started and is in progress. Set by the program. 2 = Pause - sequence is in pause state, usually awaiting operator action. Set by the program. 3 = Abort - sequence has been aborted. Set by the program. Also set by the Calculation Runtime.
Executable Enable/Disable (_Exe_Enable) (USINT) (Read Only) TRUE (=1) indicates the program is enabled. Otherwise FALSE (=0). Step Mode (_Step_Mode) (USINT) (Read Only) TRUE (=1) indicates automatic stepping within the program. FALSE (=0) for single step mode. Executable Activation Indicator (_Exe_Activation) (USINT) (Read Only) Indicates the reason for the program execution: 0 = Demand from user. 1 = Trigger from point. 2 = Periodic activation. 3 = Demand from Calculation program (via SDemand).
Failover Activation Indicator (_Failover_Activation) (USINT) (Read Only) TRUE (=1) indicates the program execution is a continuation following failover (refer Section 9.8). Otherwise FALSE (=0).
Current Step Number (_Current_Step) (UINT) Holds the current step number. Do not initialize on failover activation because execution should continue from the indicated step.
Step History (_Step_History_<step number>) (USINT) Each program holds the historical status of each step, for displaying the step box colour on the Sequence Display. A maximum of 255 steps is allowed for (the <step number> is from 1 to 255). Do not initialize on failover activation because they can be used to provide a display with seamless failover. Step history states are: 0 = not executed yet. 1 = executed successfully. 2 = currently executing. 3 = executed but failed.
Operator Message (_Operator_Message) (STRING) A maximum of 80 characters. Generated by the program for the Sequence Display. The message is not seen on the display until the program does a delay, I/O wait, etc.
Overall Sequence Elapse Time (_Overall_Elapse) (UDINT)
Page 163 of 215
9 Calculations
The elapsed time from sequence start to the current time. Do not initialize on failover activation because the overall time should include any previous elapsed time. Current Step Elapse Time (_Step_Elapse) (UDINT) The elapsed time from the current step start to the current time. User Data (_USINT_<element number>, _REAL_<element number>, _DINT_<element number>) A general purpose storage area for use by the program, containing 10 elements (numbered 0 to 9) of each of USINT, REAL and DINT type variables. For example, the name of the third variable of the REAL type is _REAL_2. Each variable is displayable and modifiable by the HMI Subsystem.
9.4.4
Sequence Control Program Example
The following program contains the framework for a basic sequence control program. This is compatible with the standard Sequence Display (refer Section 9.4.2.1) and Sequence Control Fascia (refer Section 9.4.2.2). It also contains a supervisory control function and example usage (shown shaded). Note it is not a fully working program.
(***************************************************************************** * The PointInfo type is required for doing control. ******************************************************************************) TYPE PointInfo: STRUCT PointName : STRING; CtrlOperation : USINT; CtrlParameter : REAL; ErrorCode : DINT; END_STRUCT; END_TYPE
(***************************************************************************** * FUNCTION: * DoOnePointCtrl * DESCRIPTION: * Issue a control on a point (analogue or digital). * INPUT: * pointName = the name of the point to be controlled * operation = control operation * parameter = control parameter * priority = control priority * resumeOpt = resume option * OUTPUT: * 0 = successful * 1 = failed to create control request * 2 = failed to add point to control request * 3 = failed to send control request * 4 = failed to execute control * 5 = failed to destroy control request * NOTES: * The internal data element _Operator_Message will be updated with * the result of the control. ******************************************************************************) FUNCTION DoOnePointCtrl : DINT VAR_INPUT pointName : STRING; operation : USINT; parameter : REAL; priority : USINT; resumeOpt : INT; END_VAR VAR point : PointInfo; requestID : UDINT; rqstError : DINT;
9 Calculations
error : DINT; END_VAR (* We must initialize the PointInfo structure *) point.PointName := pointName; point.CtrlOperation := operation; point.CtrlParameter := parameter; point.ErrorCode := 0; (* In the beginning, assume no error first *) error := 0; (* We call our built-in control functions *) requestID := SCreateCtrlReq(priority, resumeOpt); IF (requestID = 0) THEN _Operator_Message := 'Create control request failed'; error := 1; ELSE rqstError := SAddPointCtrl(requestID, point); IF (rqstError <> 0) THEN _Operator_Message := 'Add ' + pointName + ' to control request failed'; error := 2; ELSE rqstError := SInitiateCtrl(requestID); CASE rqstError OF 0 : (* success *) 1 : _Operator_Message := 'Bad control handle'; error := 3; 2 : IF (point.ErrorCode <> 0) THEN _Operator_Message := 'Control execution failed : ' + RtuErrToMsg(point.ErrorCode); ELSE _Operator_Message := 'Control execution failed (unknown)'; END_IF; error := 4; ELSE _Operator_Message := 'Send control failed (unknown)'; error := 3; END_CASE; END_IF; END_IF; (* Only release the control if it was created before *) IF (requestID <> 0) THEN rqstError := SReleaseCtrlReq(requestID); IF (rqstError <> 0) THEN _Operator_Message := 'Destroy control request failed'; error := 5; END_IF; END_IF; IF (error = 0) THEN _Operator_Message := 'Control successful'; END_IF; DoOnePointCtrl := error; END_FUNCTION
PROGRAM basicSCP VAR_INPUT digCtrlPoint : USINT; END_VAR VAR textStepMode : STRING; dummy, newCmd, newStep, firstTime : INT; maxStep : UINT; open, stateA, ctrlPriority : USINT; dontcare : REAL; ctrlResumeOpt : INT; END_VAR (* Initialize local variables and store constants *)
Page 165 of 215
9 Calculations
open := 1; stateA := 1; dontcare := 0.0; ctrlPriority := 1; ctrlResumeOpt := 1; IF (_Failover_Activation = 0) THEN (* If not failover, initialize local data *) _Current_Step := 1; _Overall_Elapse := 0; dummy := SClearStepHistory(dummy); firstTime := 0; END_IF; maxStep := 4; _Sequence_State := 1; (* Update the sequence state and generate an event *) dummy := SEvent('Sequence activated'); WHILE (_Current_Step <= maxStep) DO (* Check step mode after each step as we must do self-pause action, * and continue if the user sends resume or abort command. * If step mode and not first time then do pause. *) IF ((_Step_Mode = 1) AND (firstTime <> 0)) THEN newCmd := 1; textStepMode := ' (due to step mode)'; ELSE (* Get a new command in case the user wants a pause or abort *) newCmd := SNewCommand(0); textStepMode := ' '; END_IF; firstTime := 1; CASE newCmd OF 0: (* No new command *) 1: (* Pause *) _Sequence_State := 2; (* become PAUSED *) dummy := SEvent('Sequence paused' + textStepMode); newCmd := 0; WHILE (newCmd = 0) DO (* wait until new command *) dummy := SDelay(1); newCmd := SNewCommand(0); CASE newCmd OF 0: (* No new command *) 1: (* Pause *) newCmd := 0; 2: (* Resume *) _Sequence_State := 1; (* become IN-PROGRESS *) newStep := SResumeStep(0); (* get the step to resume to *) IF (newStep <> 0) THEN _Current_Step := INT_TO_UINT(newStep); END_IF; dummy := SEvent('Sequence resumed'); 3: (* Abort *) _Operator_Message := 'Sequence aborted'; dummy := SEvent(_Operator_Message); _Sequence_State := 3; (* become ABORT *) _Current_Step := 1; dummy := SAbort(1); END_CASE; END_WHILE; 2: (* Resume. Because we are in-progress, we'll do nothing *) 3: (* Abort *) _Operator_Message := 'Sequence aborted'; dummy := SEvent(_Operator_Message); _Sequence_State := 3; (* become ABORT *) _Current_Step := 1;
9 Calculations
dummy := SAbort(2); END_CASE; _Step_Elapse := 0; (* At the start of each step, reset the step elapse timer *) CASE _Current_Step OF *) 1: _Operator_Message := 'description for step #1'; dummy := SEvent('Step 1: ' + _Operator_Message); dummy := SDelay(1); (* let user see the message *) _Step_History_1 := 2; (* EXECUTING *) (****************************************************************** * * **************** Fill in step # 1 statements here **************** * * dummy := SRefresh('digCtrlPoint'); (* get the latest status *) IF (digCtrlPoint = stateA) THEN (* Check if control needed *) _DINT_1 := DoOnePointCtrl('digCtrlPoint', open, dontcare, ctrlPriority, ctrlResumeOpt); END_IF; IF (_DINT_1 <> 0) THEN _Step_History_1 := 3; (* FAILED *) ELSE _Step_History_1 := 1; (* SUCCESS *) END_IF; * * ******************************************************************) 2: _Operator_Message := 'description for step #2'; dummy := SEvent('Step 2: ' + _Operator_Message); dummy := SDelay(1); (* let user see the message *) _Step_History_2 := 2; (****************************************************************** * * **************** Fill in step # 2 statements here **************** * * ******************************************************************) _Step_History_2 := 1; 3: _Operator_Message := 'description for step #3'; dummy := SEvent('Step 3: ' + _Operator_Message); dummy := SDelay(1); (* let user see the message *) _Step_History_3 := 2; (****************************************************************** * * **************** Fill in step # 3 statements here **************** * * ******************************************************************) _Step_History_3 := 1; . . . etc, for all required steps . . ELSE _Operator_Message := 'Sequence aborted: invalid step number'; dummy := SEvent(_Operator_Message); _Sequence_State := 3; (* become ABORT *) _Current_Step := 1;
(* Find out the current step number and act accordingly
9 Calculations
dummy := SAbort(3); *) END_CASE; _Current_Step := _Current_Step + 1; *) END_WHILE; dummy := SEvent('Sequence finished'); _Sequence_State := 0; *) _Current_Step := 1; *) END_PROGRAM
(* force exit
(* Increment the current step
(* Reset the sequence state back to IDLE (* Reset step number back to 1
9.5
Calculations Configurator
The Calculations Configurator is a module of the Database Configurator. A text entry screen provides viewing, editing and compilation. The Configurator checks for syntax errors, and produces a structured text image ready for the link phase. The sources and structured text image are stored in the development database. Selecting programs, user-defined functions or user-defined data types presents an alphabetical list of sources. The sources are entered in a portable text format, substantially compliant with the Structured Text language defined in the IEC 1131-3 standard. A new source can be entered, or an existing source can be selected from the list. Sources can be saved (with user confirmation), copied, and deleted (with user confirmation). Individual or all sources in the list of the currently selected source type can be compiled, using the Compile or Compile All options, respectively. Compilation errors are remembered for each source, and are listed when the current source is displayed. Selecting an error in the list, highlights the erroneous expressions or parts thereof in the source text, and supplies information on appropriate corrective measures. When a calculation program has been compiled without any errors, it can be stored ready for the link process by performing by a calculation program install. Note that this is not related to a database install and does not affect the online system. Once installed, a user-defined type or function is available for use by other user-defined types, functions and programs, just like built-in types or functions. Calculations can be prepared independently of the system using a text editor. The ASCII text file is then imported into the Calculations Configurator. Calculations can also be exported to a text file for external use.
9.6
Calculations Linker
The Calculations Linker is a module of the Database Configurator. It produces a calculation executable, by linking the program external variables with iSCADA database point attributes. It sets the executable name, activation method, priority, etc. The executables are stored in the development database. During the link phase the user maps external variable names used in a program to desired database point attributes. The same program can be linked many times to form calculation executables. This allows a generic program to be written for say monitoring and controlling a boiler, which is then linked according to each specific boiler in the system.
Page 168 of 215
9 Calculations
Task T1 Activation method and Runtime priority.
Task T2 Activation method and Runtime priority.
One task can be used to define the activation of several executables
Via the Calculation Tasks Form Executable E1 External variable links to database. Executable E2 External variable links to database. Executable E3 External variable links to database. Executable E4 External variable links to database.
Via the Calculation Executable Form Program P1
One program with different link data can produce several executables
Program P2
9.6.1
Calculation Task Form
The Calculations Task Form allows the user to create a new task, and view, modify, or delete an existing task. The activation method can be by one or combinations of periodic, triggered or on demand. 9.6.1.1 Runtime Priority
The user assigns a runtime priority. Priority 0 is the highest. 9.6.1.2 Periodic Activation
A start time and a period specify periodic activation. The start time is the time that the executable is first run on each day. The period is the time between successive activations of the executable. Some variation in actual run times is to be expected. The Calculations Runtime checks for period overrun. If the executable has not yet run from the previous activation or is still running, the next activation is ignored (i.e. the executable misses a run, refer to E3 at time 1001) and an error is logged.
E3 activation time E3 starts E3 ends E3 is delayed due to E2 Etrig is triggered E3 overruns E3 does not run for time 1001
E3
E2 E3
E3
Etrig
E1 E2 E3
E2 E3
0957
0958
0959
1000
1001
1002
1003
Notes: Priority order is Etrig (highest), E1, E2, E3 (lowest).
Periodic activation gives no guarantee of execution order irrespective of the order in which they are entered. For a fixed repeatable execution sequence of separate executables, the first executable can demand the next with the SDemand function. 9.6.1.3 Time Changes
Calculations work on local time. The period between successive activations is unaffected by local time changes. Therefore, if the time change is forward there are fewer activations in the day, if the time
9 Calculations
change is backward there are more activations are in the day. The start time is in local time, an executable with a start time of 0800:00 will run at 8.00 am even if the local time is changed for daylight saving. If the start time is during the time change period: If the time change is forward, e.g. when the time is moved forward 1 hour at the start of daylight saving, there is no time from 0200 to 0300. A start time in the range from 0200 to 0300 is mapped to the start time range from 0300 to 0400. If the time change is backward, e.g. when the time is moved backward 1 hour at the end of daylight saving, there is an overlap of time from 0100 to 0200. A start time in the range from 0100 to 0200 is run on the first pass through the time range from 0100 to 0200, and not on the second pass through the time range.
If the realtime clock is changed significantly (normally realtime clock changes are insignificant), this affects any scheduled activation (both start time and period types of activation). If the clock jumps forward, the run occurs earlier (or now, if activation time is passed). If the clock jumps back, the run occurs later. 9.6.1.4 Triggered Activation
For triggered calculations the user enters a digital point name and conditions that are to trigger the executable. Trigger conditions are (note that these are similar to the alarm attribute of a digital point): Change to A state. Change to B state. Change to A or B state. Change from normal to abnormal state. Change from abnormal to normal state. Change from normal to abnormal state, or abnormal to normal state. I.e. not abnormal to abnormal. Any change of state. Change of quality from bad to good.
If the trigger point has bad data quality, the executable is not triggered (refer Section 4.3.2). If an executable needs to be triggered on other conditions (e.g. when an analogue point is within a particular range of values, or from more than one trigger point, or some other derived relationship), the user can define a suitable triggering calculation that causes a resultant digital point to change state when the condition occurs. This digital point is used to trigger the executable. 9.6.1.5 Demand Activation
An executable can be run on demand from the sequence control fascia, or from any display by configuration. 9.6.1.6 Multiple Activations
The following options are configurable: Whether an executable is to run again after the current run is completed, for the case where it is running and further activation requests are received. It is only run once, regardless of how many requests. It is run after the squelch period. A squelch period (minimum pause between activations, in seconds). This can be zero (with no particular maximum). The configured squelch period starts after the executable has completed its run. Any following triggers within the executable run or within the squelch period are registered.
Page 170 of 215
9 Calculations
One executable run (caused by request1)
Squelch period
One executable run (caused by requests2-6)
Request1
Requests2-6 (held)
Periodic, triggered or demand activation requests
9.6.2
Calculation Executable Form
The Calculations Executable Form allows the user create a new executable, and view, modify, or delete an existing executable. The same executable name and parameters apply to all redundant copies of the executable, except for precedence that is assigned uniquely for each copy of a redundant executable. Each executable is assigned a name, and associated with a program and calculation task. A digital point can be assigned which allows the SExeAlarm function to generate an alarm. A maximum CPU time constraint can be configured. If the executable exceeds the maximum CPU time (i.e. the total time that the executable is actually running, until it suspends or ends), then the executable run is abandoned, an error is logged, and all point values normally output from the executable, have their calculation error quality flag set (the value remains unchanged). Where the possibility of an infinite loop exists, a controlled iteration variable should be used to limit the number of iterations. A calculation program can be written using database point names. By default, the Linker will link each program external variable, to the current value attribute (cvq), in the database point of the same name. Alternatively, the program variable can be linked by supplying the database point attribute path. The linked database point does not have to currently exist. The Calculations Linker performs the addition/updating/deletion of redundant calculation executables, in a similar manner that the Database Configurator does for redundant database points. When adding a new executable, its associated redundant executables are added at the same time. Executable deletion is on a per station basis.
9.7
Calculations Runtime
When the Calculations Runtime activates an executable, it interprets the instructions until the executable completes or suspends. All database point attributes required by the executable are read at the start. Results are written to database points, and processed by Core SCADA, on completion.
Page 171 of 215
9 Calculations
Executable Ex
eg every 1 min
Periodic, Priority j Input/Output Variables
Database
Calculations Interpret calcs, giving results which are stored in output variables
Executable Ey
Input/Output Variables mapped to Database Object Attributes
Calcs Runtime
System Functions
eg a digital point changes to ON
Trigger, Priority k Input/Output Variables
Calculations
The Calculations Runtime runs all the executables that have the highest priority, in turn. Each executable runs until it either suspends itself, completes its run, or exceeds the maximum CPU time constraint. The Runtime then proceeds to run the executables at the next highest priority, and so on down to the lowest priority. An executable causes a suspend when it initiates a delay, invokes a system function, or forces an update of external variables. During the suspension period other executables may run. A new run of the executable can only occur after its current run is completed. If at any time, a higher priority executable is queued, then the current executable is suspended and the new executable is run. Eventually, when all higher priority executables have been run, the suspended executable continues. Executables of the same priority are queued at the end of that priority level, so that processing proceeds through each executable in turn. Note, that the Calculations Runtime itself is only allowed to run for a fixed time slice before it gives up control to other iSCADA modules, etc. This does not affect the processing described above, other than to spread the execution over a longer period. Missing Program or Function If the Calculations Runtime cannot find the program nominated for the executable, or cannot find a function that has been called in the executable, then the executable will not run, and an error is logged.
Page 172 of 215
9 Calculations
9.7.1
Overview of Program External Data Access and Quality Handling

Database Point: Current Value all flags input Input from database (at start of executable run) all flags clear Quality Flags High Limit
PROGRAM PROG1 VAR_IN_OUT CV : REAL; Value Quality HI : REAL; Value Quality END_VAR VAR Value K,dum : REAL; Quality END_VAR dum := QualityClear(CV, 28); K := 0.0; dum := QualitySet(K, 48); IF NOT QualityTest(CV, 44) THEN IF NOT QualityTest(CV, 37) THEN CV := CV + 20.0; CV := CV + K; END_IF; END_IF; HI := CV + 10.0; END_PROGRAM
Initially (for internal variables): Value is undefined and Quality is clear Ensure Calculation Error quality flag is cleared eg set up a constant, for ORing in a flag in later statements
All input quality flags, are available for testing
All flags are propogated to result
Sets Software Tag 1 in CV (by normal propogation in equation)
CV HI
Value Quality Value Quality
Current Value not stored if Bad Only some flags are stored Other values not stored if Bad Quality is not stored
(shown here for clarity only)
Output to database (at end of executable run)
9.7.2
Variable Initialization at Program Start
At the start of the executable run, the value of external input variables is obtained from the associated database point attributes. Variables are those in VAR_INPUT, VAR_IN_OUT and VAR_OUTPUT statements. For Quality Flag Propagation refer to Section 9.7.6. Local variables are undefined. If any point attribute cannot be obtained from the database (e.g. the point does not exist, etc), then the executable run is not run, an error is logged, and all point values normally output from the executable,
9 Calculations
have their calculation error quality flag set without changing the value. Some data skewing is likely, due to the variation in acquisition time from the field to the Calculations Subsystem for different variables. Note that any database value changes during an executable run, are not copied to the variable, unless explicitly refreshed by calling a SRefresh function.
9.7.3
Variable Storage at Program End
At the end of the executable run, the value of external output variables is stored in the associated database point attributes, if the value has changed during the executable run. Variables are those in VAR_IN_OUT and VAR_OUTPUT statements. For Quality Flag Propagation refer to Section 9.7.6. The Core SCADA attribute update facility performs input and alarm processing. The cvq attribute has an associated update time, which is updated whenever the current value and/or its quality are updated. If the variable is bad (refer Section 4.3.2), and output is to the current value/quality attribute (cvq), then the value is not stored (the flags are stored). Other database point attributes do not have an associated quality, so the value is always stored. This is done so the user can see the value is in error. If the database point is in manual override or point substitution, and output is to cvq, then the value is not stored (the flags are stored). For other database point attributes, the value is always stored. If the database point is a telemetered or manual point type, then the value is not stored, the software tags only are output. If the station hosting the database point attribute is unavailable when the variable needs to be output, no output occurs (there is no error indication). Note that there is no output until the end of an executable run, unless explicitly output by calling a SWrite function.
9.7.4
Exception Handling
If a calculation exception occurs, then the executable run is abandoned, an error is logged, and all point values normally output from the executable, have their calculation error quality flag set (the value remains unchanged). Calculation exceptions occur for: Taking the square root of a negative number. Performing arithmetic operations on boolean operators. The occurrence of an internal error in a built-in function (e.g. sin result is not a valid number).
There is no calculation exception for: Division by zero, or Modulo (MOD) operation with denominator as zero. Instead, the result calculation error quality flag is set (the value is not changed). Overflow in expressions and assignment statements. For this condition, the overflow is ignored and the result is undefined.
9.7.5
Quality Flags
Each program variable and literal has a value and set of associated quality flags (see Calculation Quality Propagation diagram Raw Quality Flags). The quality flags of an external variable are setup by input from its associated database point, propagated through calculations, manipulated by quality functions, and will set the quality of its associated database point upon completion of the executable run. The quality flags of a local variable are initialized clear (the value is undefined), the flags can be manipulated by quality functions. The quality flags of a literal are always clear.
Page 174 of 215
9 Calculations
9.7.6
Quality Flag Propagation (Calculations)
If an external input variable is linked to the current value/quality attribute (cvq), then the quality flags are copied from the database point at the start of the executable run. If the database point manual override or substitute point is set, then the variables suspect flag is set and all flags that constitute bad data are cleared. If it is substitute point that is set, then substitute point bad is propagated to calculation error. Other database point attributes do not have an associated quality, so the quality flags are cleared. Internal quality propagation only occurs when an assignment statement is used. Raw Quality Flags are propagated, by ORing the operand qualities to form the result quality. Manual override and substitute point are not propagated, but set suspect in the result. This allows the result to be manually overridden by the user. The suspect flag is propagated. If an external output variable is linked to the current value/quality attribute (cvq), then the Calculation Output Quality Flags (refer following diagram) are stored (not ORed) in the database point at the end of an executable run, the remaining flags are left unchanged. They are stored even if Bad. A reduced set of quality flags is stored because some flags must not be changed (e.g. High Alarm is set by Core SCADA, Operator Tags are set by the operator, etc). The external variables quality flags that are not output to the database are only useful for internal program purposes. Other database point attributes do not have an associated quality, so no quality flags can be stored.
Page 175 of 215
9 Calculations
RAW QUALITY FLAGS

Authorised Change Control Reserved Manual Override Substitute Pt Bad Substitute Point RTU Out Of Scan Point Out Of Scan Scan Error RTU On Test Point On Test Dev Forced Data Dev Offline Dev Comms Lost Input Bad Conversion Error Over Range Under Range Calculation Error Dev Overrange Dev Ref Error Dev Invalid Initial Status
Initial Database Load
OUTPUT QUALITY FLAGS
RTU Out Of Scan Point Out Of Scan Scan Error RTU On Test Point On Test
Calculation Error
Merged on input from database Merged on input from database
Dev Restart Suspect Operator Tag 1-8 Software Tag 1-8 Alarm Inhibit Better Alarm Inh Low Alarm Inh High Alarm Inh In High Alarm In Low Alarm Control Inhibit Off-norm Entry Inh Event Inhibit Zone Event Inh Dev Chatter Flash Software Tag 1-8 Suspect
Page 176 of 215
9 Calculations
9.8

Redundancy
Redundancy is provided by: Redundant points - which ensure that the current primary database points are accessed for input from and output to the database (refer Section 8.4). Redundant calculations - by having redundant copies of the calculation executables, which take over if the primary fails (see below).
Each executable can have a redundant backup (or multiple backups), so that when any station fails, the calculations are still performed. Backup executables do not run while the primary executable is active (i.e. all activations are ignored). The user decides the residing station and precedence for each executable and its backups. Normally, calculations and their external database point attributes, are arranged together in the same station (as much as possible), to minimize unnecessary network traffic. Allocating primary and backup executables between several stations and carefully choosing the precedence, distributes the calculation processing load more evenly. In the case of a station failure, this approach also makes the system degrade more gradually.
Station A E1 (1) E2 (3) E3 (2) Station B Station C
E1 (2) E2 (1) E3 (3)
^ *^
E1 (3) E2 (2) E3 (1)
*^
Indicates which executable runs if station A fails
Executable name
Precedence
Indicates which executable runs if all stations available
When a primary executable fails over to the backup executable: 1. If the primary executable is not running because it is in idle enabled, idle disabled or nonrecoverable error mode, then the backup executable is put in that same state. 2. If the primary executable is not running because it is in squelch mode, then the backup executable is made idle (i.e. the squelch is cancelled). 3. If the primary executable is running (i.e. ready - either executing or waiting to execute, delay or I/O wait), then the following occurs: The primary executable just stops where it is (i.e. there is no attempt to store output variables into the database). Any local data (e.g. _USINT_1) would be the last stored value. The backup executable is run, with the Failover Activation Indicator requesting that the backup executable continue the calculation/sequence control.
If a station failover occurs at or just after an activation request, the executable is repeated in the new primary station. Thus there could be some overlap, depending on exactly when failover occurs. Failover Activation (to continue the calculation/sequence control) The program must be written to handle failover. The executables primary internal data elements are periodically copied to the backup (approximately every 1 sec). Thus when failover occurs, the backups local data is reasonably up to date. The internal data elements of interest are: _Failover_Activation - to indicate that failover has occurred. _Current_Step - to know where the sequence was up to. Temporary storage (for the user) - to continue on from a known state. _Overall_Elapse - to maintain overall run time.
Action to take depends upon the type of program:

9 Calculations
If the executable is a sequence control program (or any program consisting of a number of steps), it can be programmed to continue the sequence gracefully. Typically, this consists of checking if the last step (performed by the backup) was successful, and either retrying the step or moving on to the next step. If the executable is a normal calculation program, then it may just run to produce results that were not produced in the old primary.
Note that the output of most executables is performed at the end of the executable run, therefore the set of calculation results is not partially updated. However, the user should consider what outputs and actions are taken during the executable run, for the case when failure occurs between such actions. Special action could be taken, by using the features provided for sequence control programs.
9.9
IEC 1131-3 Standard
The Calculations Subsystem is based on the IEC 1131-3 standard. The standard includes high level language constructs to define complex data types, conditional execution, iteration and functions, generation of portable calculation definitions, sharing of common code between calculations. The iSCADA System implements the Structured Text language. The Instruction List language is not implemented. The Linker effectively constructs the Configuration Blocks described in the standard. To conform, it produces Tasks and Executables, these are independently configured. Some deviation from the standard is necessary for compatibility with features in the iSCADA System. The table describes the iSCADA Systems compliance with the IEC 1131-3 standard. IEC Clause 2 Common elements 2.1 Use of printed characters 2.1.1 Character set 2.1.2 Identifiers 2.1.3 Keywords 2.1.4 Use of spaces 2.1.5 Comments 2.2 External representation of data 2.2.1 Numeric literals 2.2.2 Character string literals 2.2.3 Time literals 2.3 Data types 2.3.1 Elementary data types 2.3.2 Generic data types 2.3.3 Derived data types 2.3.3.1 Declaration 2.3.3.2 Initialisation 2.3.3.2 Usage 2.4 Variables 2.4.1 Representation 2.4.1.1 Single-element variables 2.4.1.2 Multi-element variables 2.4.2 Initialisation 2.4.3 Declaration 2.4.3.1 Type assignment 2.4.3.2 Initial value assignment 2.5 Program organisation units 2.5.1 Functions 2.5.1.1 Representation 2.5.1.2 Execution control 2.5.1.3 Declaration
Compliance Compliant. Compliant. Case is sensitive in all uses. Compliant. Compliant. Compliant. Compliant. Compliant. 0 and 1 for Booleans not implemented. Compliant. Non compliant. Compliant. TIME, DATE, TOD, DT not implemented. Non compliant. Compliant. Sub-range not implemented. Non compliant. Compliant. Compliant. Compliant. No directly represented variables (%) (for addressing physical memory/inputs/outputs, as this is not applicable). Array index must be an integer or an integer variable; expressions are not supported. Non compliant. No VAR_EXTERNAL, VAR_GLOBAL (note 2), VAR_ACCESS (note 3), RETAIN, CONSTANT, AT (not applicable). See comment on clause 2.4.3. Non compliant. No function blocks. Compliant. Compliant. Not applicable to Structured Text. Compliant.
Page 178 of 215
9 Calculations
2.5.1.4 Typing, overloading, conv 2.5.1.5 Standard functions 2.5.1.5.1 Type conv functions 2.5.1.5.2 Numerical functions
2.5.1.5.3 Bit-string functions 2.5.1.5.4 Selection and comparison functions
2.5.1.5.5 Character string functions 2.5.1.5.6 Time data functions 2.5.1.5.7 Enum data functions 2.5.2 Function blocks 2.5.3 Programs 2.6 Sequential function chart elements 2.7 Configuration elements 3 Textual Languages 3.1 Common elements 3.2 Language IL (Instruction List) 3.3 Language ST (Structured Text) 3.3.1 Expressions 3.3.2 Statements 3.3.2.1 Assignment statements 3.3.2.2 Function and function block control statements 3.3.2.3 Selection statements 3.3.2.4 Iteration statements 4 Graphical Languages A B.0 Programming model B.1 Common elements B.2 Language IL (Instruction List) B.3 Language ST (Structured Text) C Implementation dependant parameters D Error conditions Notes
Compliant. Not extensible (i.e. no variable number of inputs). No BCD. Single variable functions, e.g. sin(), extra functions are provided. Multi variable functions, can only be used in expression form, e.g. A + B + C, rather than ADD(A, B, C). Where the function has a symbol (e.g. + for ADD), only the symbol is implemented. Bit shift and bitwise Boolean functions, non compliant. Selection functions, non compliant. Standard comparison functions, can only be used in expression form, e.g. A > B, rather than GT(A, B). Where the function has a symbol (e.g., > for GT), only the symbol is implemented. Only LEN and CMP are implemented. Non compliant. Non compliant. Non compliant (see note 4). Compliant. Non compliant (SFC elements are used in structuring a program for the purpose of performing sequential control functions, they provide for steps and transitions interconnected by directed links). Non compliant. This is implemented differently (see note 1). Compliant. Compliant. Not implemented. Compliant. Compliant. Compliant. Multi element variables not allowed. No function blocks. Compliant. Compliant. Not implemented. Compliant. Compliant. Compliant regarding syntax (for functionality refer above). Not implemented. Compliant regarding syntax (for functionality refer above). These parameters are discussed throughout the iSCADA System Functional Specification. Error detection is provided.
1. The IEC standards configuration block contains RESOURCE blocks, TASK statements, etc. This is not implemented in the form of statements, instead it is performed by the Calculations Linker. The Linker provides the task facility. The term activation method is used rather than task. 2. Global variables are not supported as described in the IEC standard, instead a database point must be configured, then referenced in the calculation as an external variable. 3. The IEC standard VAR_ACCESS.....END_VAR block is not supported. Variables defined in the variable input and output blocks are mapped with the Linker, and read/write according to VAR type. 4. The IEC standard function blocks are not supported. However, functions can be used instead: Function Block Feature Input of external variables. Output of external variables. Persistence of local variables. How To Do With a Function Pass as function input parameters. Use return value and store after function call. Use program local variables or external variables.
Page 179 of 215
9 Calculations
9.10
9.10.1
Period Type Calculations

Description
Period Type Calculations are time functions of single variables, running in real time (e.g. the average of a point value so far this hour). Calculation facilities are similar to the transforms provided by the History subsystem, which are calculated using history data rather than realtime data. However, due to the different method of sampling the data, the results can be marginally different. Calculations are performed using single precision floating point arithmetic. The following calculations are provided: For analogue points: Sum Average Minimum and Date/Time of Minimum Maximum and Date/Time of Maximum Rate of Change For digital points: On Time Off Time Transition Count
Calculation (Result) Point A database point is configured for each Period Type Calculation required. It holds the result and specifies the calculation type and parameters. Normal range checking, analogue input filtering, alarm processing, etc, is performed for results other than date/time. An example Period Type Calculation is a 1-hour average sampled every minute. The result period is one hour. The sample rate is one minute. Parameters are: Source Point Result Option Sample Rate Offset Result Period - Name of the source point. - Either Running Value or Completed Value (End of Period) type. - How often the calculation runs (e.g. 1 minute samples). - The delay, in seconds, before the calculation is to run. Less than sample rate. - The period over which each result is calculated (e.g. a 1 hour average).
Source Point An analogue source point can be any analogue point type (telemetered, calculated or manual). A digital source point can be either a digital 2 or 4 state point type (telemetered, calculated or manual). If the source point is the wrong type for a given Period Type Calculation (e.g. a digital is configured as the source point for Analogue Sum), it uses the point value regardless (e.g. digital value is 0 to 3). The source point may reside in a different station to the result point. When a Period Type Calculation runs, it accesses the highest precedence copy of the source point. Result Option 1. Running Value the result is updated every time the calculation runs, this gives a running result so far this period. The result is reset to zero one sample rate time after the end of the result period, thus the result is available for a short time after the end of the period. Zero is not normally seen because the first sample in the period produces a running result, unless the first sample is bad. The result quality is also updated every time the calculation runs, this gives the quality of the running result so far this period (e.g. calculation error is set if more than say 95% samples are bad, so far this result period). 2. Completed Value (End of Period) the result is stored after processing the last sample in the result period. This result is available for all of the next result period. Sample Rate The sample rate is used for three purposes:
9 Calculations
1. For Period Type Calculations that run periodically, the sample rate specifies that period. 2. For Period Type Calculations that run when the source data changes (e.g. Minimum/Maximum), with the running result option, the sample rate specifies how often the result quality is determined. 3. For Period Type Calculations, with the running result option, the sample rate specifies how long the result is to be available after the end of the result period. The sample rate is synchronized with realtime, with the specified offset. Sample rates specified in seconds are synchronized to start of given minute plus offset, minute to start of given hour plus offset, hour to start of given day plus offset, day to start of given month plus offset. The sample on the result period boundary, is included in the earlier period. The sample rate can be configured as any of the following: Seconds: 5, 10, 15, 30 Minutes: 1, 5, 10, 15, 30 Hours: 1, 8 Days: 1 Offset If many calculations are to run at the same period and the user wants to spread the load, or the user wants to ensure that an IEC or other periodic calculation has been completed first, an offset may be specified. The calculation runs with the same sample rate and result period but both offset by the specified number of seconds. For example, a 1 hour average of 5 minute samples with 2 second offset, uses sample values at 1005:02, 1010:02, 1015:02, .., 1050:02, 1055:02, 1100:02, for the hour from 1000 to 1100. The sample value at 1000:02 is the last sample in the previous hour (from 0900 to 1000). The sample value at 1105:02 is the first sample in the next hour (from 1100 to 1200). The end of the result period is 1100:02. Result Period The result period is a multiple of the sample rate, it must be at least twice the sample rate. The result period is synchronized with realtime, with the specified offset. For result periods equal to or greater than 1 hour, the result period is relative to a logical start time of day (system constant). For example, a daily average with 2 second offset and logical start time of day at 0800, has the end of the result period at 0800:02, each day. The result period can be configured as any of the following: Minutes: 1, 5, 10, 15, 30 Hours: 1, 8 Days: 1 Months: 1
9.10.2
Quality Handling
Only the source point quality flags that make the value bad are considered (refer Section 4.3.2). All other quality flags are ignored. Calculation of the result value, takes into account whether the quality of each source value is bad or not (refer Section 9.10.7). Typically, bad values are not processed into the result. No source flags are propagated into the result. The result quality indicates the percentage of bad or manually overridden source data during the period, by setting suspect or calculation error. Calculation error is the indication of bad in the result point. Specific quality handling is defined in the Period Type Calculation descriptions. The percentages are system constants.
9.10.3
Manual Override
While a result point is in manual override, Period Type Calculations are still performed internally in the point. The manual override value has no effect on the calculations. When manual override is removed, the internal result is transferred to the points value. There is no facility to zero the internal result.
Page 181 of 215
9 Calculations
9.10.4
Failures
Communications Failure After recovery from a communications failure, bad data will have already been used for the missing samples. RTU Failure/Restart If an RTU is restarted, bad data will have already been used for the missing samples. Master Station Failure/Restart Redundancy for Period Type Calculations is provided by the mechanism for redundant database points. If there is no other station to synchronize with when a station restarts, bad data is used for the missing samples. For previous result periods, the end of period processing is performed, using bad data for the missing samples.
9.10.5
Database Install
Incremental Install When the Period Type Calculation parameters for a result point are changed and incrementally installed, the calculation is initialized (typically to zero). Other point changes do not effect the result. Full Install When the Period Type Calculation parameters for a result point are changed and full installed with warmup, the calculation is initialized (typically to zero). Other point changes do not effect the result. Without warmup, previous and current period processing depends on the stale data in the point.
9.10.6
Time Changes
Period Type Calculations work on local time. If the local time changes (e.g. daylight saving time changes), or if the realtime clock is changed significantly (normally realtime clock changes are insignificant), then Period Type Calculations are affected. If the time change is forward then any missing samples are ignored, thus fewer samples are included in the result. If the time moves forward across the end of a result period, then the end of period processing is performed. If the time moves forward by more than one result period, then only the current end of period processing is performed. If the time change is backward then more samples are included in the result. If the time moves backward across the end of one or more result periods, then the end of period processing is performed again when each end of period is reached (by normal processing), giving two results for the same times (e.g. in history). Rate of Change Period Type Calculations are unaffected by local time changes because they use the time stamp of the source value, which is in UTC time.
9.10.7
9.10.7.1
Calculation Types
Sum
Result value = sum of non-bad source values. Zero if all bad. If more than say 5% samples processed are bad or manually overridden then suspect is set. If more than say 95% samples processed are bad then calculation error is set. 9.10.7.2 Average
Result value = sum of non-bad source values number of non-bad source values. Zero if all bad. If more than say 5% samples processed are bad or manually overridden then suspect is set. If more than say 95% samples processed are bad then calculation error is set.
9 Calculations
9.10.7.3
Minimum and Date/Time of Minimum
Result value = minimum of non-bad source values. Zero if all bad. If the source point is bad or manually overridden for more than say 5% of the processed period then suspect is set. If the source point is bad for more than say 95% of the processed period then calculation error is set. The Date/Time of the Minimum is stored as the update time of the result point. Therefore on a historical display the minimum value is shown with its date/time. If the minimum occurs more than once, the most recent source date/time is stored. For accuracy, this Period Type Calculation runs when the source data changes (not on sample rate). Compared to History transforms, the date/time of the minimum could be very different, where two marginally different minimums occurred a long time apart, and one was calculated by the transform to be the minimum, but the Period Type Calculation calculated the other to be the minimum. 9.10.7.4 Maximum and Date/Time of Maximum
The Maximum is calculated as for the Minimum, except the maximum value is used. 9.10.7.5 Rate Of Change
The Rate Of Change is calculated when the source value is updated (e.g. scan update, new calculation result, new manual value). It is only available as a running value type, with the result updated every time the calculation runs. There is no result period to cause the result to be reset to zero. Result value = (Ve - Vs) / (Te - Ts) where: Ve = this source value at time Te (in seconds). Vs = last updated source value at time Ts (in seconds). If Te = Ts (in seconds) then the result value is set to zero. The Rate Of Change is also calculated at the end of a sample period, when there has not been a source value update during that period. This ensures that when the source value is constant the Rate Of Change result is zero, and that when it does eventually change a recent source update time is used in the calculation. Note if the source value is decreasing the Rate Of Change result is negative, and a low alarm detects an abnormal negative rate of change. If either source value is manually overridden then suspect is set. If either source value is bad, the result value is set to zero with calculation error set. If there is no previous source value (e.g. for a new Rate Of Change periodic calculation) the first calculation produces a result of zero with calculation error set. Analogue Input Filtering (refer Section 4.2.1.8) may be configured for the source and/or result point to avoid single changes appearing as high rates of change. 9.10.7.6 Digital - On Time
Result value = time duration (in seconds) that the source point is ON and non-bad. Zero if all bad. Where: ON = 1 = A state = Close. If the source point is bad or manually overridden for more than say 5% of the processed period then suspect is set. If the source point is bad for more than say 95% of the processed period then calculation error is set. For accuracy, this Period Type Calculation runs when the source data changes. It also runs at the sample rate to keep the result updated. 9.10.7.7 Digital - Off Time
Off Time is calculated as for On Time, except the OFF value is tested for.
9 Calculations
Where: OFF = 2 = B state = Open. 9.10.7.8 Digital - Transition Count
Result value = number of state changes of the source point (not including bad). Zero if all bad. If the source point is bad or manually overridden for more than say 5% of the processed period then suspect is set. If the source point is bad for more than say 95% of the processed period then calculation error is set. For each change, the result value is incremented by one. All value changes are counted. For a 4 state point changing from A-state to B-state (or B-state to A-state), two changes are counted when two discrete contact changes are detected. A change, exactly on the result period boundary is included in the next period. For accuracy, this Period Type Calculation runs when the source data changes (not on sample rate).
Page 184 of 215
10 History Storage and Retrieval
10
10.1
HISTORY STORAGE AND RETRIEVAL

History Storage
The History Subsystem has its own database (the history database) for storage of all history data, this is separate to the main database (e.g. realtime database). Configuration allows the user to select which database object attributes are to be collected and the storage option for each attribute. History data changes for a given attribute are stored uncompressed in either unique or common storage: The user configures Unique storage for attributes that change frequently, such as telemetered and calculated point value and status. Data compression can be configured. The user configures Common storage for attributes that change infrequently, such as analogue point alarm limit, digital point normal state. Data cannot be compressed. Storage and retrieval access is marginally slower than unique storage.
10.1.1
Data Compression
Data compression is where history data for an attribute, for several consecutive times, is replaced by one value. This reduces the amount of data stored for the attribute. Only some attribute types can be data compressed, for example, analogue point current values. There is no compression for status points. Compression results in a loss of data resolution. It is not possible to exactly reproduce the original data after compression. Compression is configured per attribute. Data compression is used in two places: In the history storage process to change uncompressed data to compressed data. Optionally in history requests to return compressed history data.
In history storage, data is compressed after being in uncompressed form for some minimum specified time (e.g. 12 hours). The minimum time delay before compression is performed, is a History Subsystem parameter, which is configured according to the amount of disc space available, and the specific project. If a disturbance is active, compression is not normally performed on any attributes in the domain (refer Section 10.1.2). The following types of data compression are available: Delta compression (with optional double delta). Fixed sample frequency. Delta Compression (with Optional Double Delta)
10.1.1.1
Delta compression is used for analogue type data. It is based on ignoring small changes in the data that are less than a specified delta value. A double delta option allows for sudden movements of a significant amount. The user parameters are: Delta value (in engineering units). Double delta value (in engineering units), optional. Flag to ignore disturbances in compression process (i.e. compress regardless of disturbances).
Where a function call is used, the call is as follows: delta(<delta value>,<double delta value>,<flag to ignore disturbances>) Parameters can be omitted where the default is suitable. The delta change between the next time tagged sample and the previous sample that was retained is determined. If the delta change is less than the delta value specified, then this next sample is ignored. The process is repeated until a sample is found that is to be retained, this sample then becomes the basis for further comparisons. One problem with the delta change approach is the case where a value has been stable for some time
(within the delta of the last retained sample), then suddenly moves a significant amount. Storing the new value only, does not properly reflect the change. Software retrieving the data, is unaware of the previous small changes that was current at the time the large change was stored, and would merely interpolate between the two values to find any intermediate values. To avoid this problem, the delta compression algorithm includes a double delta option. If enabled, this causes two samples to be retained when such a change occurs. The diagram shows that where the change is larger, both the new value and the value preceding it are retained. This gives a better fit when representing the change as an interpolation between delta samples. Of course, this is at the expense of more samples being retained.
Interpolated result (with double delta) Xn
Interpolated result (no double delta)
X0
Xn-1
Double delta band (centered on Xn-1)
Delta band (centered on X0)
Uncompressed data (input to algorithm) Retained as compressed data Retained as compressed data
Two packets are retained if: | Xn - X0 | where: n X0 Xn Xn-1 10.1.1.2 is the number of samples since the last retained sample. is the last retained sample. is the current sample. is the previous sample. is the delta value. is the double delta value. and | Xn - Xn-1 | and n > 1
Fixed Sample Frequency
Fixed sample frequency compression is for analogue type data. It is based on retaining values at a fixed sample frequency, regardless of the size of change. Although this will normally result in a reduced amount of data (i.e. where the raw data is continually fluctuating), it could also increase the amount of data (i.e. where the raw data is steady). The user parameters are: Time interval between samples (in seconds). Flag to ignore disturbances in compression process (i.e. compress regardless of disturbances).
Where a function call is used, the call is as follows: sample(<time interval>,<flag to ignore disturbances>) Parameters can be omitted where the default is suitable. The result is a series of time stamped samples, at the fixed sample frequency. Each sample is the previous known value at that time. There is no linear interpolation between previous and next known values. This is on the basis that changes between stored values are small, and that an actual stored
value is the best estimate of the true value at that time.
10.1.2
Disturbance Data Storage
Disturbance data storage prevents all data compression in a station, for a time period around the disturbance trigger. The time period covers the configured pre-trigger and post-trigger periods.
Normal storage (compression) Disturbance data storage (no compression) Normal storage (compression)
Pre-trigger period
Post-trigger period
Time
Trigger
Disturbance data storage is configurable (on a per point attribute basis), thus the user can configure data compression to occur regardless of any disturbances. When multiple triggers occur, subsequent triggers within the squelch period are ignored (see Trigger2 below). A subsequent trigger after the squelch period, but within the post-trigger period, extends the disturbance data storage period (Trigger3). New post-trigger and squelch periods are established, from the new trigger. And so on with any further multiple triggers. Normal compression resumes after the post-trigger period of the last accepted disturbance trigger.
Disturbance data storage (caused by trigger1) Disturbance data storage (caused by trigger3)
Pre1 Squelch1
Post1 Post3 Squelch3 Trigger1 Trigger2 (ignored) Trigger3
If a trigger follows, very shortly after the resumption of normal compression, the pre-trigger period may overlap with that previous disturbance data storage period. Thus, the new disturbance data storage appears as an extension of the previous disturbance data storage. 10.1.2.1 Disturbance Trigger Points
Disturbance triggers are configured in each History Station requiring disturbance data storage. A trigger point is a digital point, typically a calculated point. Any number of disturbance triggers may be defined for each system. If the trigger point has bad data quality (refer Section 4.3.2), a disturbance is not triggered. The Database Configurator provides the following options for each trigger point: 1. The disturbance trigger attribute. This defines, for what changes of state a trigger is to be generated. Valid trigger attributes (note these are similar to the alarm attribute of a digital point) are: Trigger for changes of state to B state only.
Page 187 of 215
Trigger for changes of state to A state only. Trigger for changes of state to A state or to B state only. Trigger for changes of state from normal state to abnormal state only. Trigger for changes of state from abnormal state to normal state only. Trigger for changes of state from normal state to abnormal state, or abnormal state to normal state only. Trigger for any changes of state.
2. Pre-trigger period (e.g. 10sec, 5min). This can be zero. 3. Post-trigger period (e.g. 1000sec, 200min). This can be zero. 4. Squelch period (e.g. 150sec, 5min). This can be less than, equal to, or greater than the posttrigger period; or it can be zero. All these may be changed by incremental installation. 10.1.2.2 Disturbance Occurrence Information
When a trigger condition is detected, the disturbance trigger point name and time that describe the disturbance occurrence are historically stored, archived and retrieved, just like any other history data. By displaying disturbance occurrences on a Historical Tabular display, the user can find all occurrences of disturbances, during the time period of interest. A disturbance is not recorded as a special type of event. However, the user can set the event attribute of the trigger point in the normal way, and use a category bit to identify disturbance triggers for event filtering purposes.
10.1.3
Data Collection
Attribute values are only stored when changes occur. These values are stored with a time stamp. Therefore, the history retrieval can reproduce the original data as if it had been continuously stored. All attributes are treated singularly, except for point current value/status and quality, which are always treated as a composite pair. Both the current value/status and quality are stored when either changes. The History Subsystem stores floating point values in IEEE 32-bit floating-point standard format. In this format, pulse accumulator inputs are recorded to a precision of 23-bit mantissa. History Analogue Input Filtering The history subsystem can perform value filtering on collected history analogue data. A system wide parameter, set in a system startup file (disabled by default), defines a percentage of the engineering unit range which is used to calculate a delta value in engineering units for each analogue point collected for history. Only changes larger than the delta from the previously stored value are stored in history. Input filtering is most effective on installations using the Conitel RTU communications protocol. 10.1.3.1 Time Stamp
All history data is stored with a time stamp. If the attribute has a time tag, which is already associated with the data before history collection (e.g. point current value), then this will be used as the history time stamp. For example, RTU time tagged analogues and digitals, the time that FEP records a status change during data acquisition, the time when a calculation result was stored, etc. Time tagged digitals via Conitel SOE are not seen by the History Subsystem (refer Section 4.2.5). If the attribute does not have an associated time tag (e.g. analogue high limit), then the History Subsystem will use the current time as the history time stamp. 10.1.3.2 Missing Data
Occasionally, an attribute value may not be able to be collected and/or stored, even after any catch-up operation has been performed. To indicate periods when an attribute value was unavailable, a value is stored with a history quality flagged Missing Data (which also sets Input Bad). This applies to all types of attributes and storage. This quality tag can also indicate when the history subsystem was offline.
Page 188 of 215
10.1.3.3
RTU Time Tagged Data After a Communications Outage
While there are no RTU communications, the master station tags all points in that RTU with scan error (the value is the last before failure occurred). This data is stored by the history subsystem. When communications are re-established with the RTU, and that RTU sends time tagged data, the RTU data is inserted into history in the correct time sequence, together with the original stored bad values. If the history storage for this time has already been compressed, the RTU data is discarded. For any discard an operator action event is generated. The RTU data does not replace any item of history data already stored. Where a time tag is the same as an existing item, the RTU data is placed just prior to the existing item. Note that manually overridden data remains unchanged, with RTU data stored in history regardless of periods when the point is in manual override. History retrieval returns all data for the point, regardless of quality (e.g. where manual data is interleaved with RTU data, all data is returned).
Time History during comms outage 12.48 12.52 12.52 F
manual override applied.
Data in RTU buffer
History after comms recovery 12.48 12.52 12.57 12.52 F 12.63 12.68 12.40 M 12.59 12.53
08:21 08:24 08:28 08:30 08:40 08:42 08:44 08:45 09:02
scan error detected.
12.57 12.63 12.68 12.59 12.53
scan error flag remains unchanged. old data is inserted. old data is still inserted even though manual override is on.
12.40 M
10.1.3.4
Retrospective History Processing After a Communications Outage (Optional)
Retrospective history processing provides an alternative method of processing old time tagged data from a RTU, following recovery from a communications failure. Refer Section 4.2.4.1. Retrospective history processing differs from the previously described RTU time tagged data recovery in that current RTU data is presented for history storage interleaved with the old time tagged data from the RTU. The RTU data is inserted into history as described in Section 10.1.5. Except that the data is stored with a retrospective history quality flag, to identify it from normally collected history data.
Time History during comms outage 12.48 12.52 12.52 F
manual override applied.
Data in RTU buffer
History after comms recovery 12.48 12.52 12.57 RH 12.52 RH 12.63 RH 12.68 RH 12.40 M 12.59 RH 12.53 RH
08:21 08:24 08:28 08:30 08:40 08:42 08:44 08:45 09:02
scan error detected.
12.57 12.63 12.68 12.59 12.53
scan error flag changed to retrospective history. retrospective history. retrospective history is still inserted even though manual override is on.
12.40 M
10.1.4
Quality Flag Propagation (History)
Each point current value/status has an associated set of quality flags. It is not necessary for all quality flags to be stored in history, some are combined and others are ignored. The propagation of quality flags from the database point to the history quality is shown in the following diagram. It is this quality that is presented when historical data is displayed (using appropriate runtime annotation).
Page 189 of 215
RAW QUALITY FLAGS

Authorised Change Control Reserved Manual Override Substitute Pt Bad Substitute Point RTU Out Of Scan Point Out Of Scan Scan Error RTU On Test Point On Test Dev Forced Data Dev Offline Dev Comms Lost Input Bad Conversion Error Over Range Under Range Calculation Error Dev Overrange Dev Ref Error Dev Invalid Initial Status
Initial Database Load 0 0 0 0 0 0
HISTORY QUALITY
Manual Override
Retrospective History (set by hist) Edited History (set by hist)
RTU Out Of Scan Point Out Of Scan Scan Error RTU On Test Point On Test (these flags are overridden by Substitute Point, if on) Input Bad
Missing Data (set by hist)
Initial Status
Dev Restart Suspect Operator Tag 1-8 Software Tag 1-8 Alarm Inhibit Better Alarm Inh Low Alarm Inh High Alarm Inh In High Alarm In Low Alarm Control Inhibit Off-norm Entry Inh Event Inhibit Zone Event Inh Dev Chatter Flash In High Alarm In Low Alarm Control Inhibit Suspect Operator Tag 1-8 Software Tag 1-8 Alarm Inhibit
Page 190 of 215
10.1.5
Redundancy and Catch-Up
For projects requiring full redundancy, distributed history is located in each of the stations containing redundant database objects. Each station collects history from the realtime database in that station. The station precedence determines which station is currently the primary and backup distributed history stations. Thus, the History Subsystem provides the same distributed and redundancy facilities as the database. Arrangements are one or more single History stations, or primary/backup History Station sets for redundancy. A typical arrangement of a single system (domain) is shown.
HMI
Realtime Database and History LAN
History Archive
The replication and synchronizing of data between servers discs gives transparent access to data in the event of server hardware failure. If the primary station fails, the backup station takes over. When the primary station recovers, the primary enters a phase of catch-up where distributed history is reconstructed from the history database on the backup station. When synchronization is complete, it then automatically fails back. While the primary station is synchronizing its data from the backup station, it does not accept manual failback, but will fail back if the backup station fails. If this occurs, there will be a loss of some history data (i.e. it does not attempt to finish the catchup later when the other station recovers). Similarly, if the backup station fails and recovers, while the primary station is available, the backup enters a phase of catch-up where distributed history is reconstructed from the history database on the primary station. When synchronization is complete, it is then available to takeover should the primary station fail. While the backup station is synchronizing its data from the primary station, it does not accept manual failover, but will failover if the primary station fails. If this occurs, there will be a loss of some history data (i.e. it does not attempt to finish the catchup later when the other station recovers). An event is generated when history catchup starts and when history is synchronized. History Archive Station History Archive can be configured on any station that has a DVD RAM drive. It is an optional software component. Typically, a single History Archive Station (i.e. non-redundant) configuration is used, because data is already buffered in the distributed stations history database; all historical data can be archived without loss, following a period of History Archive Station outage. For example, if the archiving is weekly, and distributed history holds four weeks of data, no data is lost if the History Archive Station is repaired within three weeks. Multiple (redundant) History Archive stations may be configured, if preferred. Each History Archive Station works independently, constructing archive files and storing them on DVD RAM, according to its configuration. Archived data is retrieved from the highest precedence archive station (this precedence is unrelated to the default station precedence). After a long History Archive Station outage, the DVD RAM disc can be manually updated by copying archive files from another History Archive Stations DVD RAM disc. History retrieval is from the highest precedence History Archive Station. For redundant History Archive Stations, staggered initiations help reduce excessive processing load, caused by each archive station retrieving history data from the primary distributed History Station. Normally archive is initiated automatically. Optionally, by configuration, archive can be initiated manually. This is for projects, which employ additional script based archive functionality, including a means of starting the archive function.
Page 191 of 215
10.1.6
Time Clock Correction
The iSCADA System operates on Universal Coordinated Time (UTC). Correction to local time is handled in the presentation. If the local time changes (e.g. daylight saving time changes), it does not affect the History Subsystem. If the realtime clock is changed significantly (normally realtime clock changes are insignificant), this does affect the History Subsystem. If the clock jumps forward there is a jump in the time stamps. If the clock jumps back then there may be an overlap, which may affect history retrievals.
10.1.7
10.1.7.1
Configuration
Object/Attribute Configuration
For each database point object requiring historical storage, a history collection definition object is used to specify the list of attributes to be stored. A history collection definition and its allocation to point objects is configured using the Database Configurator. A limit of 5 attributes can be stored per point. To assist the user, a default set of attributes is shown on the initial display of the configuration form. The default set depends on the object class (type of object), and currently consists of the current value/status and quality attribute. Current value/status and quality work as a composite pair, therefore selection of current value/status, automatically includes quality flags such as operator tags, etc. To display attributes such as engineering units, high/low alarm limits, along with the current value, those attributes must also be stored. The user needs to specify, for each attribute, the following parameters: History storage type (e.g. time stamped floating-point value with quality, time stamped text string). An appropriate default is presented for each type of attribute. Whether for unique or common storage. Whether to archive (this is for each object, not for each attribute). Compression type and parameters, if any. Flag to ignore disturbances in delta compression process - this is for each object, not for each attribute. The default setting is do not ignore (i.e. so that disturbances are processed normally).
The History Subsystem maintains records of the history configuration and all its changes, for each given object. 10.1.7.2 Adding/Deleting Objects and Attributes
If a new attribute is added for historical storage by incremental installation, all necessary storage space allocation and history setup is performed dynamically. There is no need to restart the History Station. The new data is collected and stored from the time of database update. If an object is deleted from the database, or attributes are re-configured as not to be stored, then those attributes are simply not stored any more. Their history remains intact up to the last stored sample. Therefore, they can still be retrieved. 10.1.7.3 History System Parameters
The following system parameters define the History System setup, they are used at system creation. They do not normally change, but may be changed using the Database Configurator followed by an incremental install. Distributed History Configuration Minimum time delay before compression. Storage release tidemark. To nominate when old storage blocks should be released for new storage (a percentage of the total storage space).
The amount of disc storage for the Distributed History Subsystem is estimated as shown in Section 10.4. Archive Characteristics
History Archive reserved disc space. Presence of DVD RAM for archiving. Preferred period for archive files. Preferred delay before performing periodic archiving.
10.2
History Archive
Archival is the process of gathering data from the distributed history storage and creating an archive file on disc, then archiving the file to removable DVD RAM disc. Each archive file contains the history data for all objects, in the domain, for the configured archive period (typically one week). The file starts and ends on fixed time boundaries (e.g. hourly archives start on the hour, daily archives start at midnight). Archive DVD RAM discs can be removed and stored away indefinitely. Section 2.10 describes archive management. Archive files are created on disc automatically at the configured time for archiving. They are then automatically copied to DVD RAM disc. Any archive file that still exists on disc can also be manually copied to DVD RAM disc. Archiving is also initiated when the registered archive disc is mounted and the archive list contains overdue archive jobs. Archive files can also be manually created on disc, for any previous archive period where the data is still available. This is useful where an archive file has been accidentally deleted, or a DVD RAM disc has been damaged, and the archive files need to be re-created. After a file has been archived to DVD RAM it can be deleted from disc. This can be automatic or manual. A file cannot be deleted until it has been archived to DVD RAM, unless the operator requests forced deletion. Archive files that are not deleted, stay on disc until a new archive file needs to be created and the specified maximum disc space size for archive files has been reached. In this case, if an archive file has not been archived to DVD RAM (e.g. the DVD RAM has been unavailable for several weeks), then the file is not deleted, and a new archive file is not created. The process stalls until either the DVD RAM is available, or old archive files are forcibly deleted. Alarm points can be configured for the disc full and DVD RAM disc full conditions. Archive files can be manually restored from DVD RAM disc to disc, if desired, but this is usually unnecessary (refer Section 2.10.2). History archive uses a command script to interface to the DVD RAM. The script can be tailored to suit particular DVD RAMs. It may also be modified to interface to any external storage device that can be accessed by Unix file system commands. In all cases, the maximum total external storage space that can currently be handled is 4.2TB (4200GB).
10.3
History Requests
History Data Requests provide users with historical data from distributed history station databases, and centralized archive storage files on disc and currently mounted DVD RAM discs. History determines where to get the data (the user is unaware of where the data originates). Retrieval occurs in a seamless manner, without operator intervention. Multiple historical requests can be handled concurrently. Data from DVD RAM is queried directly from the files on DVD RAM disc. To run a query covering several archived files, which are currently not all online, can be handled by restoring some of the archive data to disc, so that a previous archive DVD RAM disc can be mounted. If any portion of the request time span is not currently available, the query still proceeds and returns whatever data is found. It is the responsibility of the user to mount the appropriate archive DVD RAM disc, prior to a request. This missing data time span is marked as missing data, in the same way as if the data was just missing in a file. Transform functions (refer Section 10.3.1) enable calculations to be performed on the retrieved historical data. A request for history data consists of the following parameters:
Object and attribute name. Start date/time and end date/time. Also an optional offset if fixed sample frequency format. The format for the returned data (default is raw history data). Optionally, the name of a transform that is to be applied to the raw history data (default is none).
The point current value/status attribute has an associated set of quality flags. All other stored attributes use history quality flags to indicate missing data only. These quality flags are returned with requested data. Format The format specifies the form that the history data is to be returned in. The format is applied after any transform is applied. The following can be specified: Raw history data. Delta compressed data. Fixed sample frequency compressed data.
Raw history data returns a series of time stamped data, for an object attribute, directly from its storage in history. Therefore, it returns the original sample data, if still available in uncompressed storage, else the compressed data is returned. Data from uncompressed storage is change only data, whereas data from compressed storage depends upon the type of compression. The use of compression in a request is independent of any compression that has been configured for the attribute. Also, if data has already been compressed in history storage, it cannot be uncompressed, but could be further compressed. Requests for Disturbance Data A request for disturbance occurrence data returns a set of descriptions for disturbance occurrences.
10.3.1
Transforms
Transforms are time functions of single variables (e.g. the average of a point value over an hour). They are calculated on retrieved raw data from history, when the request is made. The transform returns a resultant value and quality. There is no limit checking, alarm processing, etc, performed. The following transforms are provided: For analogue points: Sum Average Standard Deviation Minimum Maximum Rate Integral For digital 2 or 4 state points: On Time Off Time Transition Count
Unless specifically stated, each transform follows the same basic principles described below, only the algorithm is different. The average transform is used as an example throughout this section. For each transform the requestor specifies the following: Source object/attribute Transform type Start date/time Sample rate Result rate - Name of the source data (must be in historical storage). - The transform type (e.g. average). - The date and time for the first result. - How often the source data is retrieved from history (e.g. using 5 minute values). - The period over which each result is calculated (e.g. a 1 hour average).
Page 194 of 215
Request period
- The total period of time (time span) for the results (e.g. from 0300 to 1000).
The exact function call depends upon where it is used. Further details are provided in the iSCADA System HMI Engineers Manual. For example, when requesting data for an historical display, the user specifies the function call with the source object/attribute and request period provided by the DDO. The diagram shows an example of an average transform.
1 hour average, using 5 minute values, of point xyz001 current value, from 0300 to 1000
Raw value from history Result rate (period) Transform type Sample rate (period)
Request period
Transform results
Calculated to here
03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00
Sample Rate The sample rate is synchronized with realtime. Sample rates specified in seconds are synchronized to start of a given minute, minute to start of a given hour, hour to start of a given day, etc. For example, a 5 minute sample rate with a request period starting at 1022, uses sample values at 1025, 1030, 1035, 1040, etc. Depending on the transform (e.g. for sum, average, etc), where samples are exactly on the result period start and end, only the sample at the result period end is used (otherwise a sample would be used twice). For example, a 1 hour average, using 5 minute values, from 1000 to 1500, uses sample values at 1005, 1010, 1015, ......... 1050, 1055, 1100 for the result at 1100. The sample value at 1000 is not used. For some transforms the sample rate is fixed (therefore not supplied by user), as per transform descriptions. For configuration, the rate is specified in a text string, consisting of a number and units of time (e.g. 10secs, 200mins, 1hour, 1day, 1week). Result Rate The result rate is synchronized with realtime. The first result returned is for the request period start. Thus, the period of the first result extends back in time and ends on the request period start, e.g. a 1 hour average with a request period starting at 1050 returns results for 1050, 1150, 1250, etc. The last result returned is for the last result time which is less or equal to the request period end. The result rate should be a multiple of the sample rate. If not, then results are still returned, making the best possible assumption. No error is given. The result rate must be at least twice the sample rate. If not, then the returned result is of one sample. No error is given. For configuration, the rate is specified in a text string, consisting of a number and units of time (e.g. 400secs, 5mins, 48hours, 1day, 1week, 1month, 1gasday, 1gasmonth). The result period start time for day is 0000. The result period start time for gasday is defined by a system startup file parameter for history gas time. The result period start time for month is 0000 on the first day of the month. The result period start
time for gasmonth is defined by the system startup file parameter for history gas time, on the first day of the month. Request Period As for normal historical requests, historical values sufficient to cover the request period are returned to the requestor. Therefore, when the request period is greater than the result period, several transform results are calculated and returned. 10.3.1.1 Quality Handling
Although each source point value is stored in History with quality, only those flags that make the value bad are considered (refer Section 4.3.2). All other quality flags are ignored. Calculation of the transform result value takes into account whether the quality of each source value (within the result period) is bad or not, as outlined in the transform descriptions. For most transforms, bad values are ignored. However, for a few transforms (e.g. sum) it is more acceptable to use an approximate value (that is bad), rather than to ignore the bad value (which would then be equivalent to using zero). No source flags are propagated into the result. The result quality indicates the percentage of bad source data during the result period, by setting suspect or bad. Quality handling for each transform type is identical, except for the rate transform. If more than 5% samples during the transform period are bad then suspect is set. If more than 95% samples during the transform period are bad then bad is set. The percentages are fixed in software. 10.3.1.2 Analogue - Sum
Returns the arithmetic addition of the samples. The function call is: sum(<sample rate>,<result rate>) The sum transform is calculated as follows: Result value = sum of all source values (i.e. including bad) Bad source values are included (i.e. better than using zero). Double precision arithmetic is used for improved accuracy. 10.3.1.3 Analogue - Average (Sample Frequency Method)
Returns the arithmetic average of the samples. This transform is implemented using a sample frequency input data approach. The function call is: ave(<sample rate>,<result rate>) The average transform is calculated as follows: Result value = S / N where: S = sum of non-bad source values. N = number of non-bad source values. If N = 0, the result value is set to zero. Double precision arithmetic is used for improved accuracy. 10.3.1.4 Analogue - Average (Linear Interpolation Method)
Returns the arithmetic average of the samples. This transform is implemented using linear interpolation of the raw data. The function call is: avl(<result rate>) The average transform is calculated as follows: Result value = A / T where: A = area below the curve that connects all raw samples (i.e. including bad) inside the result period.
T = length (time) of the result period. The start/end value (boundary values) for a given result period are calculated by linear interpolation with the adjacent sample before/after the period. If there is no sample after the period end, within 5 minutes, then the last sample in the period is used. Bad source values are included (i.e. better than using zero). Double precision arithmetic is used for improved accuracy. 10.3.1.5 Analogue - Standard Deviation
Returns the arithmetic standard deviation of the samples. The function call is: std(<sample rate>,<result rate>) The standard deviation transform is calculated as follows: Result value = sqrt {(N * SQ - S2) / (N * (N-1))} where: S = sum of non-bad source values. SQ = sum of squared non-bad source values. N = number of non-bad source values. If N = 0 or 1, the result value is set to zero. 10.3.1.6 Analogue - Minimum
Returns the arithmetic minimum of one second samples of the source point. The function call is: min(<result rate>) [, y] The minimum transform is calculated as follows. The sample rate is always one second. Result value = minimum of non-bad source values If all source values are bad, the result value is set to zero. By default, the timestamp returned is time of the result period end in which the minimum occurred. Optionally, the timestamp of the minimum can be returned. If there is more than one sample with the same minimum value in the sample period, then the timestamp associated with the earliest sample is returned. The optional behavior is invoked by either: Definition of a system startup file parameter. Or, by specifying an additional parameter y in the transform function call (see above). The transform function call parameter overrides any setting of the system startup file parameter, and can be n to force the behavior off. Analogue - Maximum
10.3.1.7
Returns the arithmetic maximum of one second samples of the source point. The function call is: max(<result rate>) The maximum transform is calculated as follows. The sample rate is always one second. Result value = maximum of non-bad source values If all source values are bad, the result value is set to zero. Optionally, the timestamp of the maximum can be returned. If there is more than one sample with the same maximum value in the sample period, then the timestamp associated with the earliest sample is returned. The optional behavior is invoked by either: Definition of a system startup file parameter. Or, by specifying an additional parameter y in the transform function call (see above). The transform function call parameter overrides any setting of the system startup file parameter, and can be n to force the behavior off.
Page 197 of 215
10.3.1.8
Analogue - Rate
Returns the arithmetic rate of change of one second samples of the source point. The function call is: rate(<result rate>) The rate transform is calculated as follows. The sample rate is not used. Result value = (Ve - Vs) / (Te - Ts) where: Vs = source value at time Ts. Ve = source value at time Te. Ts = time at start of result period (in seconds). Te = time at end of result period (in seconds). If either source value is bad, the result value is set to zero and the result quality is set to bad. 10.3.1.9 Analogue - Integral
Returns the arithmetic addition of one second samples of the source point. The function call is: inte(<result rate>) The integral is calculated as for the sum transform, except that the sample rate is always one second. Double precision arithmetic is used for improved accuracy. 10.3.1.10 Digital - On Time
Returns the time duration that the source point is ON. The function call is: onTime(<result rate>) The on time transform is calculated as follows. The sample rate is not used. Result value = time duration (in seconds) that the source point is ON (including bad) where: ON = 1 = A state = Close For the whole result period, all source values (with their times) that are stored in History, are analyzed to determine the total time that the source point is ON. Bad source values are included (i.e. better than using zero). 10.3.1.11 Digital - Off Time
Returns the time duration that the source point is OFF. The function call is: offTime(<result rate>) The off time transform is calculated as for the on time transform, except the OFF value is tested for. where: OFF = 2 = B state = Open 10.3.1.12 Digital - Transition Count
Returns the number of changes of state of the source point. The function call is: tc(<result rate>) The transition count transform is calculated as follows. The sample rate is not used. Result value = number of changes of state of source point For the whole result period, all source values that are stored in History are analyzed. For each change, the result value is incremented by one. All value changes are counted. For a 4 state point changing from A-state to B-state (or B-state to A-state), two changes are counted when two discrete history changes are detected. A change, exactly on the result period boundary is included in the next period. Bad source values are included (i.e. better than using zero).
Page 198 of 215
10.4
Distributed History Storage Space
The approximate storage space required for distributed history data can be determined by the following formula: Disc storage space (Bytes) = 20 x Expected number of point samples to be stored Note: the factor of 20 allows for 16 bytes, and a 25% overhead, for each sample stored (same for all point types). History data storage is change-based. Therefore, discs should be dimensioned for worst case expectations. Tools are provided for users to monitor the fixed (and DVD RAM) disc usage (refer Section 2.9.6). The number of point samples that are stored depends on the configuration of the system, and system activity. The user should take into account the normal activity, and also activity due to regular plant control and abnormal disturbances. The recommended maximum distributed history storage space is currently 6GB. The distributed history storage space is created with a Unix script when the system is built. If more space is subsequently needed, the Unix script can be used to increase the size, without affecting currently stored history data. The following is an example for a 10,000 point database station (4000 analogue points and 6000 digital points), delay before compression = 1 day, history storage for 1 year, with system activity stated below: Number of Samples per day Uncompressed History: 4000 analogue points, at 1 minute sample rate. 6000 digital points: Minimum of once per day. Routine activity of 10% changing status, 5 times per day. Major disturbance of 80% changing status, once per day. Subtotal (Uncompressed History) Compressed History: 4000 analogue points: Minimum of once per day. Average of 24 samples per day. 6000 digital points: Minimum of once per month. Average of 0.5 samples per day. Subtotal (Compressed History) Total disc space 5,760,000 Number of Days 1 Storage Space Required 115,200KB
6,000 3,000 4,800
1 1 1
120KB 60KB 96KB 115.5MB
4,000 96,000 200 3,000
1 1 1 1 365
80KB 1,920KB 4KB 60KB 753.5MB 869MB
Page 199 of 215
11 ODBC SQL Interface
11
ODBC SQL INTERFACE
The ODBC SQL Interface package is an additional option to the Standard System. Customers requiring this package should contact the regional Invensys sales representative. The ODBC SQL Interface Server can be configured to execute on any iSCADA station, either alone on an iSCADA station or co-resident with other subsystems. Several office applications can access data via a single SQL Interface. The number of concurrent users is restricted by the license limit. Connectivity from the iSCADA station (on which the SQL Interface executes) to the office network is engineered on a project basis. A typical arrangement of a single system (domain) is:
Office Applications
PCs
Office Network
HMI
SQL Interface
Realtime Database and History LAN
Archive History
11.1
Office Connectivity
The ODBC SQL Interface Server on the iSCADA Station The ODBC SQL Interface package is supplied with all necessary components for the iSCADA Station. Typically it may be configured to execute on a Solaris HMI Station. The ODBC SQL Interface is based on the Open Database Connectivity (ODBC) interface architecture with the aim of supporting office applications on the client machine that comply with the ODBC standard (i.e. Microsoft ODBC 2.5 Specification). Communications to the client machine are across a TCP/IP network. An interactive SQL command line program is distributed with the server for accessing the SQL interface on the server machine. Office Applications on the Client Machine The ODBC SQL Interface package is supplied with the OpenAccess ODBC Driver (a product of Automation Technology Inc) for the client machine. The customer is responsible for supplying the office applications on the client machine, interconnected by TCP/IP Ethernet networking. Currently the ODBC SQL Interface supports the following: Microsoft Excel 97 with Microsoft Query 2.0 or later, running on a Windows NT PC. Interactive SQL (ODBC), which is distributed with the client software for the SQL Interface. Third Party Microsoft ODBC 2.5 compliant applications such as Oracle and Microsoft Access can use the SQL Interface to connect to the iSCADA system.
11.2

Data Access
The following subset of iSCADA data is accessible through the ODBC SQL Interface: Realtime and static point information from telemetered, calculated and manual points. Realtime and static communication information concerning channels, routes and RTUs.
Page 200 of 215
Historical point value and quality information. Event information.
Data is accessed through the ODBC SQL Interface, as if the data is stored in a relational database table. Each table contains a collection of fields, where each field is an attribute of an iSCADA data object. For a full description of attributes refer to the iSCADA System ODBC SQL Interface Users Guide. The tables available are: POINTS Point information for a limited set of attributes. Including: Point name, point description, point value and quality (raw quality flags), engineering units, last update time. Point information for an extended set of attributes. Contains the same attributes as table POINTS and also most other point attributes (useful for engineering type analysis). Channel information. Including: Channel ID, channel type, protocol, address, state, and communication statistics (such as number of requests sent last minute, number of errors last minute, number of bytes transmitted/received today). Route information. Including: Route ID, protocol, state, and communication statistics. RTU information. Including: RTU ID, RTU state, route state, and communication statistics. Historical point data. Including: Point name, point value and quality (history-stored quality flags) of the sample, sample date & time, sample h_interval, sample number. History data can be returned in two formats: EVENTS Sampled history returns data for a point at a specified sampling frequency. Raw history returns a row of data for a point when a point attribute has recorded a change.
EXTENDPOINTS
CHANNEL
ROUTE DEVICE HISTORY
Event information. Including: event date and time, event text, point name, alarm group, area, category and event annotation.
The ODBC SQL Interface needs to know the current iSCADA database configuration. The user exports the configuration information from the iSCADA Database Configurator, initially and whenever the configuration is changed. The exported file is then stored at a known location for each ODBC SQL Interface Server on the iSCADA station, and the user restarts the ODBC SQL Interface Servers.
11.3
SQL Query Statements
Requests for iSCADA data use ANSI standard SQL query statements. The ODBC SQL Interface supports a subset of ANSI SQL, as defined in the following sections. For a full description of SQL query statements and their usage refer to the iSCADA System ODBC SQL Interface Users Guide. Applications such as Microsoft Query provide a user-friendly method of creating SQL query statements from a series of windows and menus. Microsoft Query allows the resulting SQL query statements to be viewed and edited, and new SQL query statements to be entered.
11.3.1
Realtime Data Requests
Realtime data requests are as follows: SELECT [field1 [,field2 [,field3...]]] FROM table1 [,table2 [,table3...]] [WHERE [condition1 [AND|OR condition2 [AND|OR condition3...]]]] [GROUP BY group1 [,group2 [,group3]]] [ORDER BY [order1 [ASC|DESC] [,order2 [ASC|DESC] [,order3 [ASC|DESC]]]]] Where:
field1, etc, are the fields in the table to be accessed (e.g. myName, dpValue, dpQualityA). If no fields are specified the entire table is returned. A field can be modified using a simple expression containing numeric operators (+, -, *, /) with other fields or numeric literals as the other operand (e.g. dpValue * 2). Support is also provided for the DISTINCT, COUNT, MAX, MIN and SUM numeric functions (e.g. MAX(dpValue)), and the DISTINCT, LENGTH, LOWER, UPPER, MAX and MIN string functions (e.g. LENGTH(myName)).
tablename is the table name (e.g. POINTS). Table expression syntax is supported. condition1, etc, provide boolean conditions to filter the data retrieval (e.g. myName = Tran33kv02) (e.g. dpValue > 0). Bracketed compound conditions are supported. The addition and difference of two expressions, and the multiplication and division operator, are supported. The condition clause is written as follows, supported operators are shown in the table below: <field> operator <constant> Operator Description Equals (=) Does not equal (<>) (!=) Is greater than (>) Is greater than or equal to (>=) Is less than (<) Is less than or equal to (<=) Contains (IN) Does not contain (NOT IN) Compare all values (ALL) Like (LIKE) Not like (NOT LIKE) Is Null (NULL) Is not Null (NOT NULL) Supported for String Attributes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Supported for Numeric Attributes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No Yes Yes
The operator LIKE performs queries using wildcards (_ for a single character, % for multiple characters). To refer to a literal underscore character when using the LIKE operator, use the backslash escape character, e.g. LIKE R3\_Tran%. group1, etc, allows the data to be sorted into logical groups based on a point attribute. For example group the results by className would return all the results for a particular type of point together. Note: for GROUP BY, all fields that appear in the SELECT field must also be present in the GROUP BY field. order1, etc, allows the data to be sorted into ascending or descending order by one field (order1), then another field within that (order2), then another field within that (order3), etc. (e.g. dpArea ASC, className DESC, myName ASC).
For example, to retrieve the value and quality of points from the realtime database, group the results primarily by dpvalue and order these resulting groups by myName descending: SELECT myName, dpValue, dpQualityA, dpQualityB FROM POINTS WHERE myName LIKE Tran%
GROUP BY dpValue, myName,dpQualityA, dpQualityB ORDER BY myName DESC;
11.3.2
History Data Requests
History data requests provide three ways for retrieving history data. The ODBC SQL Server determines the history query type automatically based on the conditions specified in the WHERE clause of a query. That is, if either the h_interval or sample columns are specified in a WHERE clause, the query is processed as a fixed frequency sampled query rather than a raw history query. The iSCADA history transforms are not accessible through the SQL interface. However, the standard SQL functions listed in Section 11.3.1 can be used with history queries.
1. Raw history data. Raw history queries return change data for points. A start date for the query must be specified otherwise an error is returned to the user. For example, to retrieve all raw data for point telana000 from 11-May2000 to 11-May2001 between the hours of 10am and 11am on each day, a raw data query could be specified as follows: SELECT * from POINTS WHERE myName=telana000 AND DATE>=11-May-00 AND DATE<=11-May-01 AND TIME BETWEEN 1000 and 1100; The values returned in the h_interval and sample columns are undefined. There is no limit on the number of rows that can be returned for a query, unless it uses the GROUP BY and SORT BY clauses. For GROUP BY and SORT BY clauses the upper limit is dependent on the hardware configuration. For a row where the point value has changed without changing a quality bit, the point quality entry is blank. 2. Delta compressed data (not supported in current release). 3. Fixed sample frequency data. The following start date/time (date1, time1), h_interval (interval) and the number of samples (numSamples) information is added to the WHERE clause (note: an offset is not supported in current release). Up to 5000 rows can be returned for each SCADA point in a query. AND date = date1 AND time = time1 AND h_interval = interval AND sample = numSamples; In the current release, time can only be specified to a resolution of one minute. For example, to retrieve 500 data values for the points Gen1_Volts and Gen2_Volts at a sample rate of 30 seconds starting from the 9am on the 10-March-2002, as fixed sample frequency data: SELECT date, time, dpValue FROM HISTORY WHERE (myName = Gen1_Volts OR myName = 'Gen2_Volts') AND date = 10-Oct-02 AND time = 900 AND h_interval = 30sec AND sample = 500; Note: For backward compatibility the date column format for the history tables is not the same as the date column format used for the events tables (Section 11.3.3).
11.3.3
Event List Requests
The Event List can be accessed as a table through the ODBC SQL Interface. A start date for the query must be specified. For example to retrieve the date, time and event text for all events in alarm group 1 since 11-December-2002 the following query could be used: SELECT Date, Time, EventText from EVENTS WHERE AlarmGroup = 1 and Date > 2002-12-11; In the current release, access to the event archives is not supported by the ODBC SQL interface.
11.4
Security
The ODBC SQL Interface provides data access security with a combination of protection facilities. A summary of the security is: 1. Each user has a user name and password. The password can be set in an SQL Interface users
Page 203 of 215
12 Applications
file or alternatively the current Unix server password can be used. For increased security the Unix server password should be used. The users name and password are encrypted before being transmitted over the network. 2. The administrator can restrict the users access to specific tables. For example, the user can be allowed access to the POINTS and HISTORY tables, but not the EXTENDPOINTS, CHANNELS, ROUTES and DEVICES tables. 3. The administrator can restrict the users access to points in specific areas for the POINTS, EXTENDPOINTS and HISTORY tables. For example, the user may be restricted to viewing points associated with generation, but not points associated with transmission or distribution. 4. The ODBC SQL Interface is read only to guarantee iSCADA system data integrity. When the office user commences a session with the ODBC SQL Interface, the user must login. An error is returned if the user name or password is not valid. At the end of the session, the user logs out. An entry is inserted in the ODBC SQL Server log for each significant change of user state (e.g. for each login, login failure, logout, failure, etc). The log entry contains the user name.
11.5
Failures
The handling of error conditions is dependent on the office application used. For example, Microsoft Excel for Windows displays the error within a window on the screen. Possible failures: An unacceptable SQL statement. The station containing the data fails. If the station containing the ODBC SQL Interface Server fails, any current connections to office applications are disconnected. The response of the office application is dependent on its own failure detection. Users need to manually establish connection to the ODBC SQL Interface when it is available again. The ODBC SQL Interface treats failure of a network path (between the ODBC SQL Interface and its client) as a disconnection.
11.6
Redundancy
The ODBC SQL Interface has limited support for redundancy. The ODBC SQL Interface Server needs to be installed on multiple iSCADA Stations. In the case of an iSCADA system server failure, the user can manually connect to the alternative SQL server.
12
12.1
APPLICATIONS
Application Programming Interface (API)
The Database Application Programming Interface (API) is used by applications to access information in the database. The API connects into the distributed Database Subsystem, which collects all data requested and returns it to the application. In the other direction, it delivers commands or controls to the addressed objects. Network connection between the distributed servers is handled by fault tolerant network services, and is transparent to the application. There are two interfaces available for the user when writing application programs: 1. The Object Interface Library: The Object Interface Library (OIL) is the user API to the iSCADA System. It provides a programming interface for customer written applications. It is a C language interface. Functions include fetch, store and command. For details of supported functions refer to the iSCADA System OIL Manual. 2. The Database API:
Page 204 of 215
12 Applications
The Database API (DAPI) is an interface to data and call functions within the iSCADA System. It is a C++ language interface, for details of supported functions refer to the iSCADA System DAPI Manual.
12.2 Application Management Support

Refer Section 2.13.4.
12.3 Optional Applications

The applications in this section are additional options to the Standard System. Customers requiring these applications should contact the regional Invensys sales representative.
12.3.1
Dynamic Network Colouring (DNC)
This is particularly useful for complex networks, with many sources and gates, where it is not obvious that a network segment is connected to a source. The colouring indicates connectivity only, it does not imply that the source is active. Gates give the network a dynamic property, they allow network segments to be either connected or disconnected to sources. A network consists of: a) Network segments, which are static elements in the network (e.g. bus bars, pipelines). b) Sources, which supply the network (e.g. generators, pumps). c) Gates, which are switchable elements in the network (e.g. circuit breakers, valves). The topology of a network refers to the static connectivity of network elements that give the network its operational properties. It does not consider the geography of the network. Sources in the network are often called colour spread points, with colour boundaries at either the utility boundaries or at the voltage level change boundaries (for an electrical network). Colouring indicates segments that are connected to the colour spread points and colour areas. Connection does not imply that the source is energized. For example, in an electrical network, when a power station generator is running and the associated circuit breaker is closed, power is supplied to a transmission line. On the line diagram, the transmission line has been configured to show a particular colour for each generator. The operator can readily see which generator is supplying the transmission line. DNC is intended for three different types of network: power, gas and liquid. Currently only type power is supported. DNC consists of a Topology Configurator to prepare a graphical representation of the network topology, and a Topology Processor that performs a topology analysis based on the configuration data for the network and current gate states. Network elements and topology information consist of: Source - sources are network supply or colour spread points (e.g. generators, pumps). Sources are connected to network segments via gates or direct connection. A segment may have multiple sources. The maximum number of sources is 7. The source is defined as a DNC system parameter. This is a list of source names in a userdetermined order. The user configures the network segment HMI DDOs with colours that match this order (e.g. the Topology Processor will set the 5th bit for the 5th source, which the DDO will test for and display the appropriate colour for that source). Gates - gates are network switchable elements (e.g. circuit breakers, valves). A gate isolates network segments. It has an associated digital point in the iSCADA database. The point corresponds to a real-world switching device. The colour of the gate symbols is determined by the state of the corresponding device, not by the Topology Processor. Segments - segments are static network elements (e.g. bus bars, transmission lines, transformers, pipelines). There is no corresponding point in the iSCADA database (but see segment status), segments are managed entirely by the DNC software.
Page 205 of 215
12 Applications
Network Segment Status - a network segment status indicator is attached to segments where the user needs to know the connectivity of the segment. It has an associated calculated multi-state digital point in the iSCADA database. The point presents the status of the associated segment, as one of many possible states, that is used to display a colour. Links - links represent connections between elements in the network being modeled. They connect sources, gates, and segments. A link is shown on the network schematic diagram as a line. Cross Reference a cross reference is used to connect network elements instead of using a link. This is for network elements on different diagrams (i.e. direct links cannot traverse diagram boundaries). A cross reference can be used for network elements on the same diagram where a direct link is untidy. Topology Configurator
12.3.1.1
The Topology Configurator is a separate program, invoked by the user. It is used to prepare network schematic diagrams and configure network elements. The network schematic diagrams are separate to the line diagrams for the realtime system. Separate islands as well as looped and radial networks can be handled. The user selects the network type when starting the Configurator. The user can create, edit, save, copy (save as), delete network schematic diagrams. Notes can be added, modified and deleted. If the drawing area is too small it can be extended using the scrolling bar. The network representation can consist of a number of diagrams. A diagram can be printed via the Topology Configurator or the HMI print window. The topology elements are generic. For example, a circuit breaker in a power network, or a valve in a liquid network, would both be converted to a gate in the topology configuration. A traction section status indicator in a power network would be converted to a pressure indicator, while a flow indicator in a liquid network would be converted to the generic flow indicator. Symbols representing network elements are selected and placed on the drawing area, by mouse selection and click. Symbol names come from the association made with database points. Symbol and symbol names can be moved to a new location by mouse drag. Symbols are connected with horizontal or vertical lines, by mouse click on the start and end symbol. Removing a symbol also removes the lines that are attached to it. Moving a symbol moves the lines attached to it. Each element type has a minimum and maximum number of allowed connections, and a list of valid connections. The maximum number and connection type is checked when connections are made. The minimum number is checked by the check and export functions.
Page 206 of 215
12 Applications
This association of gates and network segment status with database points is made (and changed) using the Topology Configurator database point list. The refresh point list function produces an up to date list of points from the online iSCADA database, including a list of sources. The select points function can be used to selectively filter the list when assigning a point to a drawing object. The Topology Configurator export function generates a single topology configuration, from all diagrams of the selected network type. If there are any unmatched cross-references or if any other inconsistencies are identified, the user is warned and the export operation fails. A check facility provides the same checking as export but only on the current diagram. 12.3.1.2 Topology Processor
The Topology Processor is a separate iSCADA process that uses the topology configuration from the Topology Configurator and current data from the realtime database. It analyses the topology, propagating source information to every segment connected to that source, and stores the results in the network segment database points for SAMMI to display. When a gate status change occurs in the network, the Topology Processor re-establishes the overall network connectivity, calculating the current state of each network segment, and updates the corresponding network segment database points with the source connection information. A segment can be connected to more than one different colour source at the same time. The network segment status points are used to display the colour of the associated network segments. Any errors that are detected in the configuration data are written to the Topology Processor log. If the DNC system parameters (list of sources) are changed the Topology Processor must be restarted. The user with Unix commands manages backup and test versions of the topology configuration. A button is provided for distributing the topology configuration throughout the system. Another button is provided for restarting the Topology Processor to use a new/modified topology configuration. The Topology Processor resides in stations containing a Core SCADA, it is started by the system. It has a start-up delay that is configurable to suit the system it resides in. The Topology Processor will operate in a redundant configuration, but only as cold standby. In case of failover the Topology Processor is re-started automatically after the start-up delay but has to run a full initialization phase.
Page 207 of 215
12 Applications
12.3.1.3
HMI Displays
Network segment symbols on the line diagrams are configured with colours to illustrate the connectivity of the network. The colour cannot be changed online. Typically different colours are used for: Connected (several colours) - the network segment is connected to a source. A different colour can be used for each possible source, or source colours can be grouped as necessary. Disconnected (one colour) - the network segment is not connected to a source. Grounded (one colour) - the network segment is connected to a ground. This is a special case of a source, i.e. it is a source called ground. Inconsistent (one colour) - topology processing for the network segment encountered bad data or an error condition, giving rise to incomplete or inconsistent information (e.g. a circuit breaker status is bad or in an indeterminate state). Also indicates that the Topology Processor has not yet started up.
Page 208 of 215
13 Database Configurator
13
DATABASE CONFIGURATOR
The Database Configurator allows configuration of database items to be done independently of the online iSCADA System, by using a development database for the configuration. The development database can then be installed to the online iSCADA System, with optional warmup using dynamic data from the distributed online database prior to a full install of the development database. For detailed information on the Database Configurator, refer to the iSCADA System Database Configurator Users Manual.
13.1
13.1.1
Database Configuration
System Views
The database is represented in a series of graphical displays (system views), which allow the user to view, navigate and edit the database. These views include: system, station, channel, route, and RTU. Objects in the views represent the physical layout of objects in the real system. Typical objects are stations, channels, routes, RTUs, and points. Objects can be added, deleted or modified. Database forms are displayed for entering object details. Pull down menus are provided for general database operations. A tool area is included, that comprises a set of push buttons representing system view components. These may be used as an alternative to the menus. Buttons are enabled only when they are applicable to the current state of the system view. The desired functionality of a station is also configured using the Database Configurator. This can include: a database, common data, a FEP Subsystem, a HMI Subsystem, a Calculations Subsystem, a History Subsystem, an archive ability and applications.
13.1.2
Database Forms
Database forms are used for configuring database objects that cannot be performed using the system view (e.g. RTUs, points). There are separate database forms for configuring the different objects and also for each type of point (e.g. analogue, digital, telemetered analogue, telemetered digital, analogue control and digital control point). Each form is divided into a number of pages. A page represents a related group of attributes of the class. The Database Configurator allows for configuration of redundant objects. When adding a new point, its associated redundant points are added at the same time. Point deletion is on a per station basis.
13.2
Install
There are two options for installing a development database to a realtime database, these are full install and incremental install. Up to three realtime databases can be installed to. The user selects which realtime database is to run online (e.g. by loading it via the Process Monitor window). If a new class or new attribute is added, or the data structure of a class has been changed, then database migration and full install are necessary, followed by a database restart in all stations.
13.2.1
Full Install
A full install distributes a development database to the nominated realtime database in all relevant stations. The realtime database must not be running online. Each station then requires a warm restart (i.e. the database process must be re-started). Installation is normally done to all stations in the system, optionally, particular stations can be selected to be installed. Care must be taken to avoid running stations online with a database mismatch.
Any station that is not available is skipped during the install process, those stations can be installed later when available, before they are brought back online. If there are errors during the install process, then the full install needs to be repeated.
13.2.2
Incremental Install
Limited data can be installed directly to the database without station restart. Changes are installed incrementally to each station containing the last full installed database. This last full installed database must be running online. All stations that have incremental changes need to be online. If all necessary stations are not online or there are errors during the install process, then a full install will be necessary. The current implementation of incremental install has the following limitations: Database points and their attributes, not including scan/control attributes (i.e. FEP attributes), can be incremental installed. Configuration of points to history, can be incremental installed. Incremental installation does not include any FEP attributes (Channels, routes, devices, scan rates, scan addresses, etc), Calculation Program facilities (programs, tasks, executables), Common Data (attributes, parameters, text, etc). The Database Configurator must be run in a station that is configured in the development database, and that station must be currently online, running the installed database.
The incremental install operation is a replay of all Database Configurator edit session(s) actions on the development database since the last successful full or incremental installation. Attribute updates are applied in the same order they were performed on the development database. Changes take effect as the updates are performed. For point changes, this may result in new alarm conditions/annunciation, list entries, etc. Care must be taken that changes that are incremental installable, are not built on top of other changes that are not incremental installable (e.g. using a new area, alarm group, scan rate, etc, that is not full installed). Note: If a previous incremental installation failed, the replay actions are attempted again (plus any new edits), at subsequent installation attempts. When all stations have been installed, the incremental log file is deleted.
13.3
Warmup
Warmup updates the development database with the latest values of nominated attributes from the realtime database. It is optionally carried out before a full database install. Attributes are nominated by a warmup list in the development database. The realtime database can be running online. Where an object is found in both databases, attributes from the realtime database object are copied into the development database object. Any station that is not available is skipped during the warmup process. The warmup can be repeated when all stations are available.
13.4
Merge
The merge function creates a single development database from a distributed database. The distributed database must not be running online.
13.5
Migration
When the software system is updated to a new version, it is sometimes necessary to migrate the database from the old version to the new version (in accordance with the software release notes). An existing database can be migrated, using the Database Configurator import/export function.
Objects are exported from the existing database (using the current system), and then imported into a new database (using the new system). Also the calculation sources must be imported, saved, compiled and installed (refer iSCADA System Database Configurator Users Manual).
13.6
Program dbtable
The database configuration spreadsheet program dbtable, provides a facility for manipulating an iSCADA database using a spreadsheet user interface. The database is presented as tables within a window, and provides the general features of spreadsheet handling, to allow viewing, addition, deletion and modification of database items (similar to programs like Excel). The dbtable program provides configuration of objects and their attributes via a spreadsheet presentation, rather than using the Database Configurators form approach, which only shows one point at a time, using multiple forms for its attributes. Thus dbtable makes mass reviews and changes easy to perform. The spreadsheet can be used on any database (normally the development database, as it is not recommended that an online realtime database be modified directly). It shows selected objects and selected attributes, which have been extracted from the desired iSCADA database. The spreadsheet data can be changed and stored into the database. Many useful facilities are provided for manipulating the data, as follows: Simultaneously editing multiple tables, similar to Excel, and copy/paste of data between tables. Typically used for manipulating points and their attributes. Objects other than points are also supported. The object classes are defined in the dbtable configuration file. The user selects the object attributes that are of interest for the current table, from one to all attributes. The attributes appearing in the table are in ordered depending on the selection. Attributes of special interest can be defined in the dbtable configuration file. Double clicking on any cell pops up a fascia of details, for assisted data entry. The table can be sorted by column (i.e. attribute), by double clicking on a column label (primary key). This is useful for attributes like scan/control address. Secondary key sorting can be performed on highlighted areas. General functions include: Open/close/disconnect an iSCADA database. Open/close/select tables. Copy/paste/delete/fill a highlighted area. Duplicate highlighted objects (e.g. a set of points in a RTU). Attribute bit set/clear (e.g. for quality flag word). Find, change, find next, global change, in the highlighted area. Restore the changed values, of the highlighted area, to the original values. Freeze a row or column. Data changes can be made to multiple stations. The precedence entry takes effect only when adding objects. Optionally, the cells changed since the last save can be shown coloured. Save, saves the changes made on the current table, since the last change. Errors detected by the software when the attribute is stored cause the items to be highlighted. An Error button is provided for flagging the cells, which resulted in an error during the last save. When an error occurs the cell is highlighted in red. Successive clicking on this button causes the cursor to jump to the relevant cell and its error message is displayed. Alternatively, the cursor can be placed on any error-flagged cell, then clicking the Error button to view the error message.
Page 211 of 215
14 Performance and Capacity
14
PERFORMANCE AND CAPACITY

5. Although 13,000 source code lines in a program have been compiled successfully, in practice, any program that is longer than 1000 lines is unmanageable from a software engineering perspective. 6. Programs containing 1000 inputs and 1000 outputs have been tested, which exceeds sensible programming practice. Outputs take about 10 times as long to process as inputs. Performance Performance is dependent on the hardware platform chosen to operate the system, concurrent functions, and general system load. A Database HMI with one screen is assumed, with History software not in the HMI station (although this is a perfectly valid combination). The performance of the HMI across domains depends on the WAN bandwidth. The indicative performance of the iSCADA System is as follows: FEP/Core SCADA: FEP throughput, as total data retrieved from all remote devices1 Average data retrieved per remote device1 Maximum publication rate of point data changes, for a database node to the network Maximum alarm rate Performance 138 Kbytes of data per sec 200 point values per sec2 250 points per sec (normal) 1000 points per sec (burst load) 1000 alarms per sec (burst load) 1000 events per sec (burst load)
The stated general performance and capacity is based on the following assumptions: Sun Solaris 2.8 operating system compatible workstations are used, with a minimum of 500 MB main memory, 400Mhz and 4 GB disc. The LAN has a minimum bandwidth of 100 Mbps.
General Capacity The general capacity of the iSCADA System is as follows: Item Per Domain Stations Objects Redundant copies (total number) per object Total redundant objects Per Station Points Telemetered points (per FEP station) Alarms Active off-normals Active tags (without tag notes) Active tags (with tag notes) Active channels (per FEP station) HMI Stations software-connected to a server SQL Interface number of simultaneous users Calculation source code lines per program Calculation input variables per program Calculation output variables per program Maximum 32 150,000 31 50,000 50,000 20,000 50,000 50,000 50,000 10,0002 200 43 See note4 10005 10006 10006
Maximum event rate
1. The standard system has been optimized to suit a single level of redundancy (i.e. two copies per object). 2. Recommended maximum number of tag notes at any one time, before station startup time is affected. 3. Recommended maximum. 4. The number of simultaneous SQL Interface users is limited by the number of operating system threads that can be created. The ODBC SQL Interface has been tested on a 10,000 point database, with history storage. Large realtime queries have a performance impact on the iSCADA system, which is increased for simultaneous multiple large queries (from single or from multiple users).
1. Calculations are based on telemetered point retrieval by a single FEP station, with 24 channels at 9600 baud, and a data efficiency of 60%. Assumes that the Ethernet interface can handle 200 packets per second. 2. For example, 40 point values retrieved per scan request, with 5 scan requests per second per channel (assuming 50% analogue and 50% digital).
Page 212 of 215
14 Performance and Capacity
Calculations: Typical Calculations Configurator compile time (700 line program)3 Maximum number of calculated results for simple expressions (e.g. x := y + z)4
Performance 90 sec
6. Additional time is taken to establish communications (normal scanning mode to all RTUs). This depends on the RTU configuration. History: Maximum number of point samples collected per station Maximum retrieval time for 200 samples from online history7 Performance 200 per sec 2 secs (1 point for 1 day) 6 secs (10 point for 1 day) 6 secs (1 point for 1 month) 15 secs (10 point for 1 month) 4 secs (1 point for 1 day) 12 secs (10 point for 1 day) 1 sec (simple retrievals such as trends) 3 secs (complex retrievals such as statistical histograms)
1000 results per sec
3. Depends on the size of the program. A 6,500 line program typically takes 2 hours to compile, however in practice, any program that is longer than 1000 lines is unmanageable from a software engineering perspective. 4. Performance is directly related to the complexity of calculations, the distribution and location of data objects used in the calculations, and general system load. HMI: Reduction in performance for alternative language operation. Maximum additional constant load running History Replay on a database HMI station. Performance 5% per screen
Maximum retrieval time for 200 samples from archive history7 Maximum additional time for presentation of retrieved data on a HMI screen
5% (normal run speed mode) 25% (fast run speed mode with multiplier of 40) Performance 4 mins5 10 points per sec5 6 mins5 7 mins5
Database: Maximum time for full install (50,000 objects). Maximum time for incremental install. Maximum time to start (load) a database (50,000 points) (including FEP)6. Maximum additional time for History to come online (not including any history catchup) Maximum upload rate of changed attributes to disc, per database station. Maximum object failover republication rate.
7. The performance figures are based on two concurrent queries from local users. Note: the standard system performance is aimed at a maximum of seven users of the history data, including operators, external users, and data export (which counts as one user). Retrieval times are for normal load conditions of one trend request per minute, not including presentation time in the HMI station. Retrievals involving transforms take additional time.
250 attributes per sec 1000 points per sec
5. Assumes SunFire 280R server (Sparc IV 750Mhz CPU, 2GB RAM).
Page 213 of 215
15 Definitions and Abbreviations
15
DEFINITIONS AND ABBREVIATIONS
For Definitions, Acronyms and Abbreviations refer to the iSCADA Dictionary. Others are defined below or where used throughout this document. CONFIGURATION DEFINITIONS - LEVELS OF CONFIGURABILITY 1) Configurable online System or point configuration that can be changed online. Initially defined in the database using the Database Configurator. There are two types: a) Operator changeable Can be changed online by the operator, via the HMI user interface. Incremental installable. Changed online by Database Configurator incremental install only.
b) Incremental installable 2) Factory preset
System configuration set at system startup. A database restart must be performed for changes to take effect. Cannot be changed online. There are two types: a) System constant Defined in the database using the Database Configurator (Common Data) (e.g. number of alarm zones, control reserve time out). Defined in a system startup file (e.g. an environmental variable, colours/masks defined in file rtda.dat). Changed by editing the files.
b) Startup file
3) Fixed in software
System configuration defined in the software. Cannot be changed without software rebuild. Fixed in software is also implied where a parameter has no specific reference to it being configured/set any other way (e.g. If more than 5% samples are bad, Every hour the oldest files are deleted).
CONFIGURATION DEFINITIONS - OTHER DEFINITIONS System configurable HMI station configurable Configuration is on a system basis. Can be configurable online, factory preset, or fixed in software. Configuration is on a per HMI station basis. Can only be factory preset by startup file. A database restart must be performed for changes to take effect. Configuration is on a per point basis. Is configurable online. Common characteristics of the system that are defined using the Database Configurator. These are:
Point configurable Common data
Message texts (including areas, categories, state texts, alarm and event texts). Control, alarm, event and off-normal inhibit mask mapping to quality flags. Database install warmup attributes. Incremental installable. System constants. A database restart must be performed for changes to take effect.
Page 214 of 215
16 References
16

REFERENCES
The documents and manuals listed below are referenced within this document: iSCADA System Operators Manual Part No. 5005008 iSCADA System HMI Engineers Manual Part No. 5005005 iSCADA System Database Configurator Users Manual Part No. 5005003 iSCADA System Dictionary Part No. 2005343 iSCADA System Distributed Network Protocol Implementation Part No. 2005378 Sammi Format Editor Manual - Part No. 5005201 International Standard, Programmable Controllers Part 3 Programming Languages Part No. IEC 1131-3 (IEC) Network Time Protocol (Version 3) Specification, Implementation and Analysis Part No. RFC 1305 (Public Domain) RTU50 Configuration User Manual (RTU50CFG) Part No. 2005550 RTU50 Diagnostics User Manual (TOOL) Part No. 2005552 Modicon Modbus Protocol Reference Guide Part No. PI-MBUS-300 Rev F (October 1994) (AEG Modicon) iSCADA System Modbus Protocol Implementation Part No. 2005449 iSCADA System IEC 60870-5-101 Protocol Implementation Part No. 20012314 Telecontrol Equipment and Systems (part 5 - Transmission Protocols) Part No. IEC 60870-51/2/3/4/5/101 (International Electrotechnical Commission) iSCADA System OIL Manual Part No. 5005007 iSCADA System DAPI Manual Part No. 5005002 iSCADA System Conitel 2025 Protocol specification Part No. 2005472 iSCADA System ODBC SQL Interface Users Guide Part No. 5005021 iSCADA System ODBC SQL Interface Installation Guide Part No. 5005022
The following standards have been used in the design of the system: Industry standard TCP/IP used for network communications. UNIX system calls comply with X/Opens P1170 standard and are SVR4 compatible. This encompasses the presentation of graphics using X11 protocol. Floating point values comply with IEEE floating point standards (32 and 64 bit formats). The SQL Interface complies with the ODBC (Open Database Connectivity) standard. The SQL syntax is a subset of ANSI SQL, as specified in the SQL Interface Section. IEC 1131-3. DNP 3.0. IEC 60870-5-101. Modbus. ANSI C, C++. X/OPEN MOTIF. All coding is in the programming languages C and C++. The software is designed and implemented to be portable across different hardware platforms that run SVR4 UNIX.
Page 215 of 215

FuncSpec v2.00 (For6.3)

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

FuncSpec v2.00 (For6.3)

Încărcat de

Drepturi de autor:

Formate disponibile

Functional Specification (2005415) - Rev. 2.00 (for 6.

I/A Series Intelligent SCADA System

Document ID: Revision:

2005415 2.00 (for 6.3)

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

I/A Series Intelligent SCADA System

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

I/A Series Intelligent SCADA System

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

I/A Series Intelligent SCADA System

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

I/A Series Intelligent SCADA System

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

Core SCADA Initialization ............................................................................................... 122

6.2 6.3 6.4 6.5 6.6

Off-Normal Management ........................................................................................................ 142 7.1 Analogue Off-Normals .................................................................................................... 142

I/A Series Intelligent SCADA System

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

7.2 7.3 7.4 7.5 7.6

8.2 8.3 8.4

I/A Series Intelligent SCADA System

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

I/A Series Intelligent SCADA System

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

Courier New font

I/A Series Intelligent SCADA System

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

iSCADA Master Station Overview

I/A Series Intelligent SCADA System

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

I/A Series Intelligent SCADA SCADA Platform

I/A Series Intelligent SCADA System

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

Remote Operator Terminal

Application Server Routers/ Firewalls Terminal Servers

Field Communication Communication Channels Channels

Routed DNP Over TCP/IP Ethernet Ring

Remote Access Terminal

Optical RTU LAN OEM RTU via Open Protocol

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

Networks and workstations

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

I/A Series Intelligent SCADA System

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

DNP3 IEC 60870-5-101 Conitel (2025, 2020, and C300) Modbus

Core SCADA Core SCADA provides the core processing of

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

I/A Series Intelligent SCADA System

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

Other applications on request.

I/A Series Intelligent SCADA System

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

The HMI Station

Most functionality applies to each platform except where specifically noted.

Solaris Database HMI Station

Solaris Databaseless HMI Station

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

Windows NT/2000 HMI Station (Databaseless)

2.1.4 iSCADA WebConnect (iWeb)

I/A Series Intelligent SCADA System

Functional Specification (2005415) - Rev. 2.00 (for 6.3)

HMI Data Access Failure and Failover