tested validated documented architecture modular

How Can I …

Manage alarms effectively in Vijeo Citect?

Tested Validated Documented Architecture

Modular automation system

Develop

your project


3

Important information

People responsible for the application, implementation and use of this document must make sure

that all necessary design considerations have been taken into account and that all laws, safety

and performance requirements, regulations, codes, and applicable standards have been obeyed

to their full extent.

Schneider Electric provides the resources specified in this document. These resources can be

used to minimize engineering efforts, but the use, integration, configuration, and validation of the

system is the user’s sole responsibility. Said user must ensure the safety of the system as a

whole, including the resources provided by Schneider Electric through procedures that the user

deems appropriate.

Notice

This document is not comprehensive for any systems using the given architecture and does not

absolve users of their duty to uphold the safety requirements for the equipment used in their

systems, or compliance with both national or international safety laws and regulations.

Readers are considered to already know how to use the products described in this document.

This document does not replace any specific product documentation.

The following special messages may appear throughout this documentation or on the equipment

to warn of potential hazards or to call attention to information that clarifies or simplifies a

procedure.

The addition of this symbol to a Danger or Warning safety label indicates that an

electrical hazard exists, which will result in personal injury if the instructions are not

followed.

This is the safety alert symbol. It is used to alert you to potential personal injury hazards.

Obey all safety messages that follow this symbol to avoid possible injury or death.

DANGER

DANGER indicates an imminently hazardous situation which, if not avoided, will result in death

or serious injury.

Failure to follow these instructions will result in death or serious injury.


4

WARNING

WARNING indicates a potentially hazardous situation which, if not avoided, can result in death

or serious injury.

Failure to follow these instructions can cause death, serious injury or equipment

damage.

CAUTION

CAUTION indicates a potentially hazardous situation which, if not avoided, can result in minor

or moderate injury.

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

NOTICE

NOTICE is used to address practices not related to physical injury.

Failure to follow these instructions can result in equipment damage.

Note: Electrical equipment should be installed, operated, serviced, and maintained only by

qualified personnel. No responsibility is assumed by Schneider Electric for any consequences

arising out of the use of this material.

A qualified person is one who has skills and knowledge related to the construction, operation and

installation of electrical equipment, and has received safety training to recognize and avoid the

hazards involved.

Before you begin

This automation equipment and related software is used to control a variety of industrial

processes. The type or model of automation equipment suitable for each application will vary

depending on factors such as the control function required, degree of protection required,

production methods, unusual conditions and government regulations etc. In some applications

more than one processor may be required when backup redundancy is needed.

Only the user can be aware of all the conditions and factors present during setup, operation and

maintenance of the solution. Therefore only the user can determine the automation equipment

and the related safeties and interlocks which can be properly used. When selecting automation

and control equipment and related software for a particular application, the user should refer to


5

the applicable local and national standards and regulations. The National Safety Council’s

Accident Prevention Manual also provides much useful information.

Ensure that appropriate safeties and mechanical/electrical interlocks protection have been

installed and are operational before placing the equipment into service. All mechanical/electrical

interlocks and safeties protection must be coordinated with the related automation equipment and

software programming.

Note: Coordination of safeties and mechanical/electrical interlocks protection is outside the scope

of this document.

START UP AND TEST

Following installation but before using electrical control and automation equipment for regular

operation, the system should be given a startup test by qualified personnel to verify the correct

operation of the equipment. It is important that arrangements for such a check be made and that

enough time is allowed to perform complete and satisfactory testing.

WARNING

EQUIPMENT OPERATION HAZARD

Follow all start up tests as recommended in the equipment documentation.

Store all equipment documentation for future reference.

Software testing must be done in both simulated and real environments.


damage.

Verify that the completed system is free from all short circuits and grounds, except those grounds

installed according to local regulations (according to the National Electrical Code in the USA, for

example). If high-potential voltage testing is necessary, follow recommendations in the equipment

documentation to prevent accidental equipment damage.

Before energizing equipment:

Remove tools, meters, and debris from equipment

Close the equipment enclosure door

Remove ground from incoming power lines

Perform all start-up tests recommended by the manufacturer


6

Operation and adjustments

The following precautions are from NEMA Standards Publication ICS 7.1-1995 (English version

prevails):

Regardless of the care exercised in the design and manufacture of equipment or in the selection

and rating of components; there are hazards that can be encountered if such equipment is

improperly operated.

It is sometimes possible to misadjust the equipment and thus produce unsatisfactory or unsafe

operation. Always use the manufacturer’s instructions as a guide for functional adjustments.

Personnel who have access to these adjustments should be familiar with the equipment

manufacturer’s instructions and the machinery used with the electrical equipment.

Only those operational adjustments actually required by the operator should be accessible to the

operator. Access to other controls should be restricted to prevent unauthorized changes in

operating characteristics.

WARNING

UNEXPECTED EQUIPMENT OPERATION

Only use software tools approved by Schneider Electric for use with this equipment.

Update your application program every time you change the physical hardware

configuration.


damage.

Intention

This document is intended to provide a quick introduction to the described system. It is not

intended to replace any specific product documentation, nor any of your own design

documentation. On the contrary, it offers information additional to the product documentation on

installation, configuration and implementing the system.

The architecture described in this document is not a specific product in the normal commercial

sense. It describes an example of how Schneider Electric and third-party components may be

integrated to fulfill an industrial application.

A detailed functional description or the specifications for a specific user application is not part of

this document. Nevertheless, the document outlines some typical applications where the system

might be implemented.


7

The architecture described in this document has been fully tested in our laboratories using all the

specific references you will find in the component list near the end of this document. Of course,

your specific application requirements may be different and will require additional and/or different

components. In this case, you will have to adapt the information provided in this document to

your particular needs. To do so, you will need to consult the specific product documentation of the

components that you are substituting in this architecture. Pay particular attention in conforming to

any safety information, different electrical requirements and normative standards that would apply

to your adaptation.

It should be noted that there are some major components in the architecture described in this

document that cannot be substituted without completely invalidating the architecture,

descriptions, instructions, wiring diagrams and compatibility between the various software and

hardware components specified herein. You must be aware of the consequences of component

substitution in the architecture described in this document as substitutions may impair the

compatibility and interoperability of software and hardware.

CAUTION

EQUIPMENT INCOMPATIBILITY OR INOPERABLE EQUIPMENT

Read and thoroughly understand all hardware and software documentation before attempting

any component substitutions.

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


8

This document is intended to describe how a user can effectively manage alarms using Vijeo

Citect.

DANGER

HAZARD OF ELECTRIC SHOCK, BURN OR EXPLOSION

Only qualified personnel familiar with low and medium voltage equipment are to perform

work described in this set of instructions. Workers must understand the hazards involved in

working with or near low and medium voltage circuits.

Perform such work only after reading and understanding all of the instructions contained in

this bulletin.

Turn off all power before working on or inside equipment.

Use a properly rated voltage sensing device to confirm that the power is off.

Before performing visual inspections, tests, or maintenance on the equipment, disconnect

all sources of electric power. Assume that all circuits are live until they have been

completely de-energized, tested, grounded, and tagged. Pay particular attention to the

design of the power system. Consider all sources of power, including the possibility of back

feeding.

Handle this equipment carefully and install, operate, and maintain it correctly in order for it

to function properly. Neglecting fundamental installation and maintenance requirements

may lead to personal injury, as well as damage to electrical equipment or other property.

Beware of potential hazards, wear personal protective equipment and take adequate safety

precautions.

Do not make any modifications to the equipment or operate the system with the interlocks

removed. Contact your local field sales representative for additional instruction if the

equipment does not function as described in this manual.

Carefully inspect your work area and remove any tools and objects left inside the

equipment.

Replace all devices, doors and covers before turning on power to this equipment.

All instructions in this manual are written with the assumption that the customer has taken

these measures before performing maintenance or testing.

Failure to follow these instructions will result in death or serious injury.


9

The TVDA collection

Tested Validated Documented Architecture (TVDA) guides are meant to help in the

implementation of specified solutions. TVDA guides provide a tested and validated example of

the proposed architecture to help project engineers and Alliance System Integrators during the

design and implementation of a project. The TVDA helps users analyze their architectures,

confirm the feasibility of their systems and speed up system implementation.

Each TVDA provides users with:

A reference architecture based on Schneider Electric’s PlantStruxure solution

Documentation of the system requirements of the architecture – response times, number of

devices, features

Design choices for the application – software and hardware architectures

Test results to confirm the requirements are met

All explanations and applications have been developed by both Schneider Electric experts and

system integrators in our PlantStruxure labs.

TVDAs are not intended to be used as substitutes for the technical documentation related to the

individual components, but rather to complement those materials.

Development environment

Each TVDA or STN has been developed in one of our solution platform labs using a typical

PlantStruxure architecture.

PlantStruxure, the process automation system from Schneider Electric, is a collaborative

architecture that allows industrial and infrastructure companies to meet their automation needs

while at the same time addressing their growing energy efficiency requirements. In a single

environment, measured energy and process data can be analyzed to yield a holistically optimized

plant.


10

Table of contents

1. Introduction 13

1.1. Purpose 13

1.2. Customer Challenges 13

1.3. System Context 14

1.4. Prerequisites 15

1.5. About this Document 15

1.6. Glossary 16

2. Selection 17

2.1. Selected architecture(s) 17

2.2. SCADA 19

3. Design 24

3.1. Alarm Priorities 24

3.2. Alarm Categories 25

3.3. Equipment Hierarchy 25

3.4. Sequence of Events 26

3.5. System Resource measurements 26

3.6. Alarm page display times 27

3.7. SOE page display times 28

3.8. Alarm generation rates 29

3.9. Alarm burst performance 30

4. Configuration 32

4.1. Alarm configuration 32

4.2. Alarm Servers Configuration 34

4.3. Equipment 34

4.4. Alarm Priorities 37

4.5. Displaying alarms in different fonts 37

4.6. Alarm Categories 40

4.7. Alarm pages 41

4.8. Simple alarm filter rules 41

4.9. Alarm counts on graphics pages 43

4.10. Alarm Archiving 45

4.11. Localization 46


11

4.12. Creating EEMUA Alarm Management Reports 48

5. Operation and Maintenance 55

5.1. Acknowledging Alarms 55

5.2. Disabling and Enabling Alarms 55

5.3. Comments and user events 57

5.4. Using the alarm filter form 59

5.5. Sorting 61

5.6. Alarm Equipment Page 64

5.7. Localization 67

5.8. Logging 68

5.9. Viewing the Alarm Events History Report 69

6. Validation 72

6.1. SCADA Server resource usage 72

6.2. Alarm burst performance 75

6.3. Alarm Page Display Performance 76

6.4. SOE Page Display Performance 77

7. Conclusion 78

8. Appendix 79

8.1. Glossary 79

8.2. Bill of Material and Software 80

8.3. Computer Specifications 81

8.4. Reference Documents 81

8.5. Performance Benchmark 81

8.6. Alarm Event History Report 83


12

OOOOOOO 1 – Introduction


13

1. Introduction

1.1. Purpose

The aim of this TVDA is to describe a complete Alarming system using PlantStruxure architecture

in order to facilitate its deployment.

- For Pre-sales : it will help to propose the right system by better understanding what can be

propose for an effective alarming system. It will also help to better understand the limits of the

proposed system.

- For engineering team and SI: Guideline for architecture design. It will consolidate the design,

reduce the development cost, and increase the robustness

1.2. Customer Challenges

Alarm management is a topic which is becoming increasingly important in the process industry. In

a typical day for a plant operator a lot of time can be taken in the management of alarms. The

operator needs time to detect an alarm, navigate to the relevant data in the SCADA system, analyze

and perform actions resulting from an alarm, and ensure that the alarm condition has been handled

successfully. Due to these actions required from the operator, there are guidelines on the number

of alarms which can be successfully managed by an operator. The ISA 18.2 Alarm Management

standard provides metrics regarding manageable average alarm rates, an average of one alarm

per ten minutes is very likely to be acceptable, with a maximum manageable level of two alarms

per ten minutes. Alarm rates of ten alarms in a ten minute period is not sustainable for the operator

to manage, and therefore can result in missed alarms.

As process complexity has increased, the control system operator interface technologies have also

had to improve to better communicate the abnormal conditions, which must be addressed.

EEMUA 191 and ISA 18.2 complement each other. EEMUA describes in detail the tools and

techniques for various aspects of alarm management (e.g. rationalization, risk assessments,

graphics design); whilst ISA 18.2 clearly defines the required performance KPIs and the overall

lifecycle approach to alarm management. The performance KPIs for both documents are similar.



14

1.2.1. Main considerations

Vijeo Citect 2015 provides new features focused around some core objectives: Alarm Management,

Partial Association and .NET integration. The main focus of this TVDA will be to implement alarm

features in Vijeo Citect in order to assist operators in the runtime management of alarms in their

control system.

1.2.2. Main Requirements

- Management of different alarm priorities (levels of alarm)

- Improve the Analysis phase of alarm

- Appropriate usage/display of alarms according to users within the system

- Demonstration of common alarm actions

1.3. System Context

The control network model used in this TVDA is an example of the control network in the

PlantStruxure Modular System Reference Architecture. As shown in Figure 1, this architecture

includes an enterprise level, a plant level, a process level (which includes the control network) and

a field level.

Figure 1: PlantStruxure Modular Reference Architecture

Process

Enterprise

Plant

Field

Engineering

Station

Redundant

System

Servers

Asset

Management

System

Drive

Motor

Starter

Motor

Protection

Hot-Standby

Controller PACPACSafety

Controller

Plant Floor HMI

Energy

Monitoring

Distributed IO

Operator Clients

Remote IO

Batch System

Historian

Manufacturing

Execution

System

ERP System

Remote IO

Control room

architecture

Functional Unit

architecture

Control networkOverall

Network

architecture

Operation network

Device

network

Process

Enterprise

Plant

Field

Engineering

Station

Redundant

System

Servers

Asset

Management

System

Drive

Motor

Starter

Motor

Protection

Hot-Standby

Controller PACPACSafety

Controller

Plant Floor HMI

Energy

Monitoring

Distributed IO

Operator Clients

Remote IO

Batch System

Historian

Manufacturing

Execution

System

ERP System

Remote IO

Control room

architecture

Functional Unit

architecture

Control networkOverall

Network

architecture

Operation network

Device

network



15

Plant

Plant networks carry plant and supervisory communications. Services running at this

level may include facility IT services, scheduling systems (batch), material flow

applications, manufacturing execution systems (MES) and other control-related

applications (supervisory control, historian).

Process

The process level is where PAC devices communicate with other PAC devices and

SCADA. It includes the control network, which is the specific network that carries PAC-

to-PAC and PAC-to-SCADA network communications. As the control network connects

multiple control points, it is usually designed with high availability and redundancy.

Field

The field network carries field device monitoring and control information, including PAC-

to-I/O and PAC-to-drive traffic, and is the focus of this example architecture. Field

networks are usually time sensitive and communicate directly with PAC devices.

The PlantStruxure architecture operates in an overall context that also includes an enterprise

network. Enterprise networks carry communications for business systems and day-to-day

operations such as printing, word processing, data-entry and reporting. Primarily for security

reasons, it is recommended that the enterprise network have no or very limited access to the plant,

process and field level networks.

1.4. Prerequisites

The reader should have basic knowledge of the following software applications:

Vijeo Citect 2015

Microsoft Excel 2010

Unity Pro XL v8.0

OFS v3.50 SP7

1.5. About this Document

The document methodology used in this TVDA includes the following sections: Selection, Design,

Configuration, Operation and Maintenance, Validation and Conclusion.

This guide focuses on designing and configuring an alarm system within Vijeo Citect.

A brief description of each section in this document follows:

Selection: This section details the selection procedure to define a typical set of alarm features within

a Vijeo Citect system.



16

Design: This section details the design of a Vijeo Citect systems alarm functionality

Configuration: In this section, the configuration information for the different alarm features is

detailed.

Operation and Maintenance: This section details how the configured alarm system is displayed and

how they can be used on the running system.

Validation: A summary of the architecture performance in response to simulated events is

presented in this section. This includes system resource usage on the alarm server, the time taken

to display alarm pages and the responsiveness of the system under burst conditions.

Conclusion: Presents significant results and highlights the key design choices that influence the

alarm system.

1.6. Glossary

A glossary is available in the appendix chapter of this document. Please refer to it whenever

necessary.

OOOOOO 2 – Selection


17

2. Selection

2.1. Selected architecture(s)

The proposed system comprises of a redundant pair of Vijeo Citect servers in a typical medium

sized automation system. These servers will include I/O, Alarm, Report and Trend server

functionality. Additionally a number of operator workstations running a Vijeo Citect client are used.

SCADA will be connected to ten PACs where each PAC will contain approximately 5000 tags, with

a total tag count of 50000 in SCADA.

As this TVDA will focus on alarming functionality, this system will have a mix of alarm types namely

digital and analog. It is recommended that to improve efficiency, time stamped digital alarms should

be used when DRI based drivers such as OFSOPC, DNP or OPC are used. The project is

configured as follows:

IO tags: 35000 digital tags, 15000 analog tags

Alarm tags: 20000 digital tags, 12000 analog tags

Trend tags: 5000 digital tags, 15000 analog tags

The system will include the following:

Two Vijeo Citect servers configured in a redundant setup

Four Vijeo Citect clients (operator workstations)

One real PAC and 9 simulated PAC’s.



18

Operator Workstations

Vijeo Citect

Redundant Servers

Vijeo Historian

Server

PAC’s

Figure 2: Selected Architecture

Performance testing will be carried out on systems of varying sizes using the same architecture.

Test systems will be scaled by varying the number of PAC’s, tags, alarms, trends and operator

workstations. The server architecture and the ratio between alarms and trends to variable tags will

remain unchanged.

Variable Tags PAC’s Vijeo Citect Clients

10000 2 1

50000 10 4

100000 20 8

Table 1: Project sizes for performance testing



19

2.2. SCADA

The SCADA system is responsible for acquiring real-time data from the PAC’s in the system and

displaying that data on operator workstations. The SCADA system also hosts services for alarming,

reporting and trending. In this TVDA, Vijeo Citect will be used as the SCADA system, and this

TVDA will focus on how to take advantage of Vijeo Citect’s alarming functionality.

The alarming system performs a critical function by monitoring the equipment within the system for

unexpected conditions, such as operator actions failing or process limits being exceeded.

2.2.1. Alarm Types

Alarms can be configured in Vijeo Citect via different alarms types. The choice of alarm type will be

dependent on the user needs. The types of alarms that can be configured in Vijeo Citect include:

Digital Alarms are triggered based on the state of up to two digital variables. The time associated with

the state change will be based on latest of the two variable tags timestamps.

Analog alarms are triggered when an analog value goes beyond limits that have been configured by

the user.

Advanced alarms are triggered based on the result of a cicode expression. Unlike all other alarm

types, this expression is evaluated periodically, as defined by the alarm scan rate. Other alarms types

are only evaluated only when their associated variable tag’s value changes. These give the user much

greater flexibility however this increases the processing load on the Alarm server.

Time stamped digital alarms are triggered based on state of one or two digital alarms, however the

time associated with each state change can either come directly from a PAC for drivers that use the

Driver runtime interface, or via a cicode function. The time stamp of a time stamped digital alarm has

millisecond precision.

Time stamped analog alarms are similar to analog alarms except they also contain the same time

stamping functionality that exists in time stamped digital alarms.

Time stamped alarms are triggered based on the state of up to two digital variables but the time

associated with each state change is read from another variable tag rather than using the time stamp

of the two variables tags. This requires the engineer to configure an additional variable for each alarm.

Time stamped alarms are not as precise as time stamped digital or analog alarms. With the precision

of these alarms being controlled by the parameter [Alarm] HresType.

2.2.2. Alarm Archiving

Vijeo Citect 2015 provides control over the archiving of alarm data. Alarm Archiving in Vijeo Citect 2015

is controlled by a series of parameters.



20

The citect.ini parameter [Alarm] ArchiveAfter sets the period of time in weeks after which

alarms can be archived. After this time, alarms in the system are read only. This means that

for systems using RTU based push alarms, no alarms can be injected into the system after this

time. Note that alarms are not automatically archived after this time. To archive alarms, the

user must either set the “archive every” setting on the alarm server form, or by calling the cicode

function “AlarmArchive()”. By default this parameter is set to 4 weeks. The alarm server must

be restarted after changing this parameter.

The citect.ini parameter [Alarm] KeepOnlineFor controls how long alarm data stays in the

system. After this time, the history of alarms will be removed from the system and will no longer

be displayed at runtime. If archiving is not configured, this means that alarm data will be lost

after this time. This defaults to 6 weeks. The alarm server must be restarted after changing this

parameter.

The alarm server setting “Archive Every”, controls the number of days after which alarms are

automatically archived. This setting can be found in Vijeo Citect Project editor on the alarm

servers form, which can be opened by selecting the menu item Servers \ Alarm Servers.

The event journal stores 768 bytes of data for each event that occurs within the alarm system. On

a typical system, there are three event transitions per alarm (ON, OFF and ACKNOWLEDGE). In

the system under test, in which alarms are triggered at the rate of 10 alarms per operator per 10

minutes with 4 operators for a period of 6 weeks, the event journal will require:

Event journal size = bytes per event * operators * event transitions * alarms per 10 minute *

(seconds per day / seconds per 10 minutes) * [Alarm] KeepOnlineFor (in days)

= 768 * 4 * 3 * 10 * (86400 / 600) * 42

= 531 Mb

This calculation does not include the space required for configuration, security and logging.



21

2.2.3. Graphics Page Templates

Vijeo Citect 2015 is shipped with different styles of templates that can be used to create graphics

pages. Users can choose to use one of the existing template styles or create their own templates.

Vijeo Citect contains six template styles:

Tab Style

Standard

XP Style

Bottom

Top

Version 2

Of these six template styles, four are no longer supported, and are only shipped for backwards

compatibility purposes. The four styles that are no longer supported are XP Style, Bottom, Top and

Version 2. Of the remaining two styles, this TVDA will use Tab Style templates. This template style

offers an increased amount of alarm functionality and thus reduces the amount of cicode that needs

to be written by the user.

Built into the tab style alarm templates is the ability to:

Acknowledge alarms

Enable and disable alarms

Filter and sort the alarm list

Add additional fields to the alarm list

Get a count of the number of active and disabled alarms on all pages

Display a SOE page

Display alarms and a SOE list within an equipment tree.

Add user events to SOE list



22

Figure 3: Tab style alarm page

All tab style pages contain an alarm banner at the bottom of each page. This alarm banner displays

the last three alarms that have occurred, as well as a count of the unacknowledged alarms in the

system. Alarms can be acknowledged and disabled directly from the banner meaning an operator

can quickly actions alarms without leaving their current page.

Figure 4: Alarm Banner

2.2.4. Historical Alarm Page

Historical alarms can be viewed in Vijeo Citect by using either an alarm summary or a sequence of

events (SOE) page. Both pages allow the user to display a list of historical alarms, but both have

different functionality.

The alarm summary page contains one entry for each instance of an alarm that is raised. The time

that instance of the alarm went on, off and was acknowledged, are all stored in the same record. If



23

the same alarm is raised a subsequent time, a new instance of this alarm is created in the summary

page.

By comparison, the sequence of events has a number of advantages over the summary page. The

SOE page contains one entry for each time an alarm changes state i.e. in a typical system each

alarm goes on, before being acknowledged and being turned off (or vice versa). On the sequence

of events page, this sequence of alarm state transitions will be displayed as three separate records.

The SOE page also has the advantage that comments and user events can be added to it. The

SOE page also records security information, with all login and logout events throughout the system

being stored in this same view. Vijeo Citect 2015’s filtering functionality allows these events to be

removed the SOE page, without the need for the integrator to write any cicode.

For these reasons, the SOE page will be used to display historical alarms in this TVDA.

Figure 5: Sequence of Events Page

OOOOO 3 – Design


24

3. Design

3.1. Alarm Priorities

In any alarm system it is extremely useful to prioritize the alarms in the system so that more

important alarms are more obvious to an operator. This is useful in periods of high activity, where

a large number of alarms can occur at once and the operator must choose which alarms to action

first. An alarm priority is usually based on one of two factors:

The severity of the consequence that could occur if the operator does not take the

appropriate corrective action to the alarm.

The amount of time that operator has available compared to the amount of time that it

would take to perform a corrective action.

The EEUMA 191 standard recommends that three alarm priorities should be used within one alarm

display. Many sites however have more than one alarms system. Some sites may have safety

related alarms hard-wired and a separate fire or gas alarm panel. In this situation it is recommended

that alarm priorities be consistent across all systems.

In this TVDA, alarms will be given one of the following priorities:

High

Medium

Low

However on most sites, as safety alarms are handled by one or more separate systems. No Critical

alarms will be configured in the SCADA system. Under most circumstances it is recommended that

only High, Medium and Low priorities alarms be configured within Vijeo Citect.

According to the EEMUA 191 standard, it recommends that to make it easier for an operator to

identify higher priority alarms, the frequency at which alarms occur should decrease as the priority

increases. For each increase in priority, it is recommended that the frequency at which those alarms

occur decreases by a factor of five.

OOOOO 3 – Design


25

Priority Vijeo Citect Clients

Critical Very infrequently

High Less than 5 per shift

Medium Less than 2 per hour

Low Less than 10 per hour

Table 2: Target Maximum alarm frequency

When designing a system it is difficult to know at what rate alarms will be triggered on the running

system. For this reason, during design alarms should be assigned in proportions according to Table

3: Alarm Priority breakdown. Then during commissioning, alarm priorities should be adjusted so

that the system achieves a performance similar to Table 2: Target Maximum alarm frequency.

Priority Vijeo Citect Clients

Critical About 20 altogether

High < 5% of configured alarms

Medium < 15% of configured alarms

Low 80% of all alarms

Table 3: Alarm Priority breakdown

3.2. Alarm Categories

Alarms within Vijeo Citect can be grouped together into categories. The priority of an alarm is

defined within an alarm category. Alarm categories also allow the user to define:

The font in which an alarm is displayed

The fields that are displayed when an alarm is triggered.

An action that is triggered when an alarm changes into the ON, OFF or ACK state.

Alarm log devices, such as SQL databases, dbf or text files.

Whether the alarm is displayed on the alarm, summary or SOE pages.

Alarms can also be filtered and sorted based on their category.

3.3. Equipment Hierarchy

Equipment hierarchy can be used to define plant equipment to assist on confirming with various

standards, such as the batching standard S88. Equipment hierarchy allows alarms, as well as

variable tags, trends, accumulators and other types of information to be bound to a specific piece

of equipment. At runtime this allows alarms to be displayed in an equipment tree, and gives users

a lot of flexibility to filter, sort and count alarms by its equipment.

OOOOO 3 – Design


26

3.4. Sequence of Events

The sequence of events list is a historical view of all events that have occurred in your system. An

event is logged in Vijeo Citect’s event journal view when:

An alarm changes state, i.e. if an alarm goes ON, turns OFF or is acknowledged.

An alarm is enabled or disabled.

A user logs onto the system.

A user adds a comment to an alarm

A new user event is added to the system.

The configuration of an alarm is first loaded from the project configuration.

The configuration of an alarm is changed and the alarm server is reloaded.

3.5. System Resource measurements

System resources on both the server and client machines will be measured using windows

performance monitor. CPU Usage will be measured for alarm server process, a client process

that is displaying an alarm page, and for the entire computer. This will be performed using the

counters “Process / % Processor Time” and “Processor / % Processor Time / _Total”

respectively. Memory usage will be measured for the alarm server process, a client process

displaying an alarm page and for the entire computer.

Figure 6: Configuration of Performance Monitor

OOOOO 3 – Design


27

The counter “Process / % Process Time” measures the CPU Usage of a single process on the

computer. This is measured as a number between 0 and 100 * n, where n is your total number

of logical processors in the machine. During times of high activity, it is not unusual for the value

of this counter to exceed 100%. This means that the process is using more than one of the

computer’s logical CPU’s. This counter is useful for comparing the CPU usage of a process on

different hardware, as the number will remain the same, no matter how many logical processes

the machine has.

The counter “Processor / % Processor Time / _Total” measures the total CPU Usage of for the

entire computer. This will always be a number between 0 and 100.

3.6. Alarm page display times

Page display times for both the alarm and SOE pages was measured by displaying the

appropriate page and then waiting for the first alarm record to be displayed on the page. This

measurement was performed using cicode and was measured on all display clients that are

attached to the system. The results show the average display time of all clients.

Each client connects to server and waits for signal

to start test(Initialization)

Server waits for allClients to connect

(Initialization)

`

Server signals clients

to begin test(Start of Test)

Clients display the alarm page and wait for alarms to

be displayed

ServerClients

Each clientsSends its results to

the serverServer waits for result from all

clients and takes average

(End of Test)

Alarm page display time workflow

Figure 7: Alarm page display time testing

OOOOO 3 – Design


28

3.7. SOE page display times

The performance of the SOE page was measured by displaying the page and measuring the

amount of time before a record is displayed. Once the page was displayed, a second test was

performed to measure the amount of time taken to apply a filter to the alarm page.

OOOOO 3 – Design


29

3.8. Alarm generation rates

The EEMUA standard measured alarm generation rates by measuring the number of alarms an

operator can handle within a ten minute period. This standard defines a rate one alarm per ten

minutes per operator as very likely to be acceptable, two alarms per operator per ten minutes as

manageable, and greater than ten alarms per ten minutes to be very likely to be unacceptable.

While running the system that is to be validated, alarms generation rates will be presented in this

format. Tests will be performed at the rates of one, ten and fifty alarms per operator per ten minutes.

The number of operators (clients) on each system is described in Table 1: Project sizes for

performance testing. This means that on the five different sized systems that will be tested in this

TVDA, the total number of alarms that will be generated per day is:

Alarms per operator per 10 minutes

10000 tags 50000 tags 100000 tags

1 576

10 1440 5760 11520

50 28800

Table 4: Alarms triggered per day

In a typical system, each time an alarm is triggered; it goes through three state changes:

Alarm StateOFF

Unacknowledged

Alarm StateON

Unacknowledged

Alarm StateON

Acknowledged

Alarm StateOFF

Unacknowledged

Alarm StateOFF

Acknowledged

Operator acknowledges alarm

Alarm goes off

Alarm is triggerd

Alarm goes off Operator acknowledges alarm

Figure 8: Alarm state transitions

OOOOO 3 – Design


30

Each state change is recorded as one event in the SOE page. This means that in a typical day, if

each alarm has three state changes, the event journal will record the following number of events:

Alarms per operator per 10 minutes

10000 tags 50000 tags 100000 tags

1 1728

10 4320 17280 34560

50 86400

Table 5: SOE records per day

3.9. Alarm burst performance

Alarm burst performance is measured by triggering a burst of alarms in the PAC (or the simulated

PAC’s) and measuring the time taken for the count of alarms to be updated with the correct value

on a display client. This measurement was performed using the cicode function AlarmCount(). The

results show the average response time of all display clients.

Each client connects to server and waits for signal

to start test(Initialization)

Server waits for allClients to connect

(Initialization)

`

Server signals clients

to begin test(Start of Test)

Server triggers burst of alarms in

PAC’s

Clients waitFor alarm count to

Be updated correctly

ServerClients

Each clientssends

alarm burst timeto server

Server waits for result from all

clients and takes average

(End of Test)

Alarm burst testing workflow

Figure 9: Alarm burst testing

As with the system performance tests, alarm burst performance tests will be performed on each of

the five different sized systems. However in this test, for this a percentage of variable tags in the

burst are varied, meaning that on larger systems, more alarms are triggered in the burst. The

following table shows how many alarms are expected to be triggered when a percentage of tags

are changed in each burst.

OOOOO 3 – Design


31

Percentage of tags in burst

10000 tags 50000 tags 100000 tags

5% 500 2500 5000

10% 1000 5000 10000

30% 3000 15000 30000

60% 6000 30000 60000

Table 6: Alarm burst size

OOO 5 – Operation and Maintenance


32

4. Configuration

4.1. Alarm configuration

Alarms can be defined in Vijeo Citect in a number of ways. Alarms can be defined through the

forms in project editor, in Microsoft Excel via the Microsoft Excel dbf add-in, or through the

equipment update tool. To define alarms through Project Editor, simply select the alarm type you

wish to configure from the Alarms menu, and fill in the fields appropriately. For more information on

configuring the different types of alarms, please refer to the Vijeo Citect documentation.

Figure 10: Digital Alarm Form

Creating or editing alarms can be done in bulk by using the Microsoft Excel dbf add-in. To use the

Microsoft Excel dbf add-in:

1. Start Microsoft Excel and click on the Add-In’s tab.

Figure 11: Microsoft Excel DBF-Addin tool bar

Click on “Enter new path to master.dbf”. This file stores the names and project locations

of all projects in your Vijeo Citect installation.



33

2. Browse to your master.dbf file. This is located in your Vijeo Citect “User” directory. This

defaults to “C:\ProgramData\Schneider Electric\Vijeo Citect 7.50\User\MASTER.DBF.”

3. Select your project from the “SCADA Project” combo box.

4. Select the file you wish to edit from the “SCADA Table” combo box.

Figure 12: Adding digital alarms in Microsoft Excel

5. Once you have finished editing your alarms, save your file by pressing the “Save DBF”

button.



34

4.2. Alarm Servers Configuration

In Vijeo Citect 2015 the alarm server now can run as a 64-bit process which allows the user to

configure a large system without needing to add more clusters.

To switch the alarm server to 64-bit:

1. Open the Alarm Servers form in Citect Project Editor.

2. Set the Extended Memory field to TRUE for the 64-bit alarm servers.

Figure 13: Alarm Severs Form

3. Run project.

4. Alarm server starts as a 64-bit process.

Figure 14: Runtime Manager

Processes which are running in 64-bit mode have an asterisk (*) in Runtime Manager.

4.3. Equipment

Before equipment can be used in the alarm, variable tag or trend tags forms, equipment must be

defined within your project.

To define equipment, open the equipment form. This can be found in project editor using the

menu item “Equipment \ Equipment”.



35

Figure 15: Equipment Form

Alternatively, equipment can be configured using Microsoft Excel.

Figure 16: Configuring Equipment in Microsoft Excel

When defining equipment within a hierarchy, dots are used to define a piece of equipment’s place

within the hierarchy. Please refer to the Vijeo Citect documentation for more information on defining

equipment within a hierarchy.

Once equipment has been defined alarms (as well as variable tags, trend tags, reports and

accumulators) can be linked to a piece of equipment by adding its name into the Equipment field

on the appropriate form.



36

Figure 17: Using equipment in the analog alarms form

Figure 18: Using equipment in the variable tags forms

When configuring an alarm or tag to be part of a piece of equipment, it is helpful to also configure

the item field. This is analogous to a pin name on a DFB in Unity Pro, or a property name in an

object within an object oriented programming language. Configuring this field allows alarms to be

displayed on the alarm display by equipment and item rather than alarm tag name. Item names

must be unique within each configuration form, so it is acceptable to configure your variable tags

and its matching alarm with the same item name.

Please note that when configuring equipment and item names, that the there is a 254 character

limit on the combination of the equipment name plus the item name with a dot in-between them

e.g. Area1.Section1.Input1.PV. Tags that have been configured that exceed this limit will generate

the compile error “Equipment Name and Tag Item too long. Specify or change the Tag Item field”



37

4.4. Alarm Priorities

An alarm’s priority is defined within the “Alarm Category form”. The priority is a number in the range

0-255. Lower numbers indicate higher priority alarms. However, for ease of configuration, a label

can be used in place of this number within the priority field. Label can only be used at configuration

time and cannot be used at runtime.

Figure 19: Defining priorities as labels

Configure the following labels for the four alarm priorities:

Label Name Expression

High 2

Medium 3

Low 4

Table 7: Labels for alarm priorities

4.5. Displaying alarms in different fonts

Different alarms can be configured to display with different fonts at runtime. Alarms of the same

priority can be configured to be displayed using the same fonts. This quickly allows the operator to

determine an alarms importance.

Alarm fonts are configured per category, and a different font can be configured for each of the five

states that an alarm can appear in (on unacknowledged, on Acknowledged, off unacknowledged,

off acknowledged and disabled). Font colors are defined by using labels.

Figure 20: Defining font colors as labels



38

Colors in Vijeo Citect are represented by number that can be calculated using the formula:

Color = (Blue + (Green * 256) + (Red * 65536))

Where blue, green and red represent the RGB value for that color (which is a number between 0

and 255. Alternatively, this can defined in hexadecimal as a three byte hexadecimal value with high

byte representing the red value, the middle byte representing the green value and the low bytes

representing the blue value.

In this project, three additional colors have been defined. The remaining alarm font colors have

been defined in the “Include” project.

Label Name Red Green Blue Label Value

LightOrange 256 126 43 0xFF7E2B

DarkOrange 196 77 0 0xC44D00

DarkGrey 110 110 110 0x6E6E6E

Table 8: Font color configuration

Once the labels have been defined, these can be used within the fonts form.

Figure 21: Defining fonts



39

Fonts can then be used within the alarm categories. This project has the following fonts defined.

Font Name Font Type Pixel Size Foreground Color

AlmP2OnUnackFnt Arial 10 LightOrange

AlmP2OffUnackFnt Arial 10 DarkOrange

AlmP3OnUnckFnt Arial 10 Yellow

AlmP3OffUnackFnt Arial 10 Brown

AlmP4OnUnackFnt Arial 10 White

AlmP4OffUnackFnt Arial 10 DarkGrey

Table 9: Font configuration



40

4.6. Alarm Categories

Alarms can be grouped together via alarm categories. Alarm categories allow the user to define

the fonts that an alarm is displayed in, its priority, its display format, as well as some advanced

functionality, such as on, off and acknowledge actions. At runtime, alarms can be sorted and filtered

by their category, and a number cicode functions exist that allow the user to interact with alarms in

specific categories. At a minimum, define one category for each priority of alarms. In the example

below, the contents of the “Priority”, “Unack On Font” and “Unack Off Font” are the labels that were

defined earlier.

Figure 22: Alarm Categories form

For more information on configuring Alarm Categories, please refer to the Vijeo Citect

documentation. In this project contains the following categories:

Category Priority UnAck On Font UnAck Off Font

2 HIGH AlmP2OnUnackFnt AlmP2OffUnackFnt

3 MEDIUM AlmP3OnUnackFnt AlmP3OffUnackFnt

4 LOW AlmP4OnUnackFnt AlmP4OffUnackFnt

Table 10: Alarm category configuration



41

4.7. Alarm pages

Alarm pages can be created in graphics builder. Pages have been created in this project using

the following templates:

Page Name Library Template

Alarm Tab_Style_Include Alarm

Disabled Tab_Style_Include Disabled

Alarm_Equip Tab_Style_Include Alarm_Equip

SOE Tab_Style_Include SOE

SOE_Equip Tab_Style_Include SOE_Equip

Table 11: Alarm Pages

All alarm pages from the Tab Style Include project have in-built functionality that allows an

operator to acknowledge, enable, disable, sort and filter alarms without the need for any

additional configuration.

4.8. Simple alarm filter rules

In addition to the advanced filtering functionality that is available at runtime, Vijeo Citect 2015 allows

the user to add alarm filter rules to the alarm filter dialog, without having to write any additional

cicode. This allows the engineer to add filter rules for common queries that will need to be

performed without the operator needing to build a new filter every time the alarm page is displayed.

Adding a simple filter rule to the alarm filter form can be done by opening the computer setup editor

and add the following parameters to your citect.ini file:

[AlarmFilterRules] <RuleName>

[AlarmFilterRuleList] Rule<n>

[AlarmFilterRuleList.Active] Rule<n>

[AlarmFilterRuleList.Disabled] Rule<n>

[AlarmFilterRuleList.Summary] Rule<n>

[AlarmFilterRuleList.SOE] Rule<n>

For example, to add a simple filter rule to the Active Alarm and SOE pages that only displays critical

priority alarms, configure the following parameters:

Citect.ini parameter Value

[AlarmFilterRules] High Priority Alarms Priority = 2



42


[AlarmFilterRuleList.Active] Rule3 High Priority Alarms

[AlarmFilterRuleList.SOE] Rule4 High Priority Alarms

Table 12: Alarm Filter Rules

To configure alarm filters to filter alarms based on the remaining three alarm priorities defined

above, add the following citect.ini parameters.


[AlarmFilterRules] Medium Priority Alarms Priority = 3

[AlarmFilterRuleList.Active] Rule4 Medium Priority Alarms

[AlarmFilterRuleList.SOE] Rule5 Medium Priority Alarms

[AlarmFilterRules] Low Priority Alarms Priority = 4

[AlarmFilterRuleList.Active] Rule5 Low Priority Alarms

[AlarmFilterRuleList.SOE] Rule6 Low Priority Alarms

[AlarmFilterRules] Last 8 hours #Now[-28800]

[AlarmFilterRuleList.Active] Rule6 Last 8 hours

[AlarmFilterRuleList.SOE] Rule7 Last 8 hours

Table 13: Additional Alarm Filter rules

Filter rules can also be combined together using the semicolon character (‘;’), which acts as a

logical AND.


[AlarmFilterRules] High Alarms Last 8 hours Priority = 2;#Now[-28800]

[AlarmFilterRuleList.Active] Rule7 High Alarms Last 8 hours

[AlarmFilterRuleList.SOE] Rule8 High Alarms Last 8 hours

Table 14: Combining filters in alarm filter rules

For more information on configuring simple filter rules, please refer to the topic “AlarmFilterRule

Parameters” in the Vijeo Citect documentation.



43

4.9. Alarm counts on graphics pages

Alarm counts can easily be configured on Vijeo Citect graphics pages. Alarm counts can be

configured to count the total number of alarms in an alarm list, or to count the number of alarms

that match a certain criteria. In this TVDA, I will use this functionality to build two genies. The first

will count the number of alarms in each area of the plant for an overview page, and the second will

be a flashing warning icon that will change color dependent on the highest priority of alarm for a

specific piece of equipment.

The number of alarms in an area can be displayed by creating a genie and placing a number object

on it. The cicode function AlarmCount() will be used within this genie. The area will be passed into

the genie using a genie substitution. Note that using genie substitution %Area% is not supported.

Figure 23: Using AlarmCount() on a number object.

Figure 24: Genie for counting alarms in an area

To create a genie that will change color depending on the highest priority of alarm that is occurring

for a piece of equipment, create a new genie and place a symbol set of it. Again, the cicode function

AlarmCount() will be used, but this time, the filter parameter will be set to count by priority and

equipment. This will be done by creating four animated symbol sets, which are aligned on top of

each other.



44

Figure 25: Symbol set configuration

In total, three symbol sets will be configured on top of each other, configured as follows:

Animate When Expression Frame 1 Symbol Frame 2 Symbol

(AlarmCount(1,"PRIORITY=4;EQUIP=%EQUIPMENT%") > 0)

AND

(AlarmCount(1,"PRIORITY<4;EQUIP=%EQUIPMENT%") = 0)

Ring1_white Ring2_white

(AlarmCount(1,"PRIORITY=3;EQUIP=%EQUIPMENT%") > 0)

AND

(AlarmCount(1,"PRIORITY<3;EQUIP=%EQUIPMENT%") = 0)

Ring1_yellow Ring2_yellow

AlarmCount(1,"PRIORITY=2;EQUIP=%EQUIPMENT%") > 0 Ring1_orange Ring2_orange

Table 15: Symbol set configuration



45

These genies can then be used in graphics pages, templates or other genies.

Figure 26: Graphics page configuration

For information on creating graphics pages, please refer to the Vijeo Citect documentation.

4.10. Alarm Archiving

Alarm archiving can be configured by setting a combination of alarm server settings and citect.ini

parameters. In this example, the alarm server will be configured to archive after four weeks and

keep alarm data online for six months.

Figure 27: Alarm server configuration



46


[Alarm.c1.AlarmServer1] ArchiveAfter 4

[Alarm.c1.AlarmServer1] KeepOnlineFor 26

Table 16: Archiving parameters

For more information on configuring archiving, please refer to the Vijeo Citect documentation.

4.11. Localization

The language that alarm field are displayed in can be configured to be changed at runtime. In Vijeo

Citect, the language that is displayed can be selected when a user logs in. To configure the

languages that the operator can use at runtime:

1. In Project Editor, select System\Languages to open the languages form.

2. Select the language that you wish to configure from the drop down list.

3. Configure the ANSI to OEM setting. For details on this setting please refer to the Vijeo

Citect documentation.

Figure 28: Languages configuration

4. Mark the contents of any fields that are to be translated with the language change indicator

@(). For example to mark the string “Alarm word bit 0” for translation, enter “@(Alarm word

bit 0)”. Vijeo Citect 2015 does not support the localization of partial strings. In this project,

only the contents of the “Comment” field will be marked for localization. The following fields

can be marked for translation:

Name

Description

Comment

Custom1 – Custom 8



47

Figure 29: Marking a field for localization

5. Once all of your strings have been marked for localization, compile your project. The

compiler will create the file “French(France).dbf”. This file contains the mapping between

the native (that have been marked for localization) and their local translations.

6. Vijeo Citect does not contain a facility to translate these strings. Translation can be done

by a professional translator, a native speaker of both languages, or through various online

translations services. This web site will not read dbf files, so the contents of the “Local”

column should be saved to a text file which can then be automatically translated. The

translated strings can then be copied into the “Native” column.

Figure 30: Translating strings in French(France).dbf



48

4.12. Creating EEMUA Alarm Management Reports

Vijeo Historian contains a reporting package called the Reports Deployment Manager (RDM) which

is used to deploy the EEMUA Alarm reports. The RDM contains a suite of customizable pre-

packaged alarm management reports which use SQL Server Reporting Services (SSRS) to call on

stored procedures for querying the data in the Historian database. There are a total of ten reports

within the alarm management report pack. This TVDA focuses on the Alarm Events History report

which a statistical history of alarm events over a period of time.

4.12.1. Registering a Historian Database

1. Launch the Reports Deployment Manager (RDM) from the Start Menu.

2. Right Click on the Historian Databases node Register.

3. In the Connect to a Historian database dialogue box enter the SQL Server instance:

<.\VIJEOHISTORIAN>.

4. In the Authentication section select the Use integrated windows authentication radio

button.

5. In the Database section select the Historian database which will be used to generate the

reports.

6. Click OK.

Figure 31: Registering a Historian Database



49

4.12.2. Installing Historian Standard Pack

1. Right Click on the Historian database (under the Historian databases node) Install

package. This will launch the Value pack (re)installation dialogue box.

2. In the Target database section select the Historian database.

3. In the Value Pack section, check that ‘Historian Standard Report Pack’ is highlighted.

4. Click Install button.

Figure 32: Installing Historian Pack

4.12.3. Deploying Reports

1. Expand the Reports Pack node.

2. Right click on the Historian Standard Report Pack Deploy Reports. This will open the

Deploy reports window.



50

3. Check that the Report server and Reporting services URL fields are correct and appear

similar to the figure below.

Figure 33: Deploying Reports

4. In the Data source drop down box select <new>. This will launch the ‘New reporting data

source’ window shown in the figure below.

Figure 34: Creating a new data source

5. Select the Create button. This will create a new reporting data source.



51

6. In the Deploy Reports window select the Deploy button. This will deploy the entire report

pack.

4.12.4. Creating a Folder Hierarchy

1. Expand the StandardReportPack sub node, expand also Hierarchies subnode.

2. Right click on the Hierarchies node New Hierarchy. In the Name field enter Section 1.

Click the OK button.

Figure 35: Hierarchy Properties

3. On the Section 1 folder right click New Node, enter ‘Area 1’ in the Node name field as

shown below. Click the OK button.

Figure 36: Hierarchy node properties

4.12.5. Adding Alarm Tags

4. Expand the StandardReportPack sub node, expand also Hierarchies, Section 1 and Area

1 sub nodes as highlighted in the figure below.



52

Figure 37: Showing created alarm hierarchies

5. Select the Area 1 folder and on the right pane select the Alarms tab.

6. In the empty Alarm tab, right click Add. This will open the Alarm Picker window as shown

in the figure below.



53

Figure 38: Reports Deployment Manager Alarm Picker Window

7. In the Name Filter section, enter ‘c1.Area1_’. This will filter all alarms that belong to Area 1.

8. Select all the alarms in the list as shown in the figure below.

Figure 39: Alarm picker window

9. Click the OK button. This will populate the Alarms pane with the selected Power Meter Tags.

This is illustrated in the figure below.



54

Figure 40: Showing selected alarms in the alarm tab



55

5. Operation and Maintenance

5.1. Acknowledging Alarms

Alarms can be acknowledged on the active alarm page, or from the alarm banner on any tab style

alarm page. Alarms can be acknowledged by users if they have access to the privilege defined for

that alarm, and the user has access to the privilege defined in the parameter [Privilege] AckAlarms.

By default, users must have access to privilege 1 to acknowledge alarms. Alarms can be

acknowledged by right clicking on the alarm on the active alarm page or on the alarm banner. To

allow alarms acknowledgement to be controlled through the privileges associated with each users

role, set [Privilege] AckAlarms to 0.

Regardless of the alarms configured area and privilege, and the value of the parameter [Privilege]

AckAlarms, alarms cannot be acknowledged if no user is logged into Vijeo Citect.

5.2. Disabling and Enabling Alarms

Alarms in Vijeo Citect can be disabled directly from any active alarm page or from the alarm banner,

by right clicking on the alarm and selecting “Disable” from the pop up menu. Alarms can be disabled

by users if they have access to the privilege defined for that alarm, and the user has access to the

privilege defined in the parameter [Privilege] DisabledAlarms. This parameter defaults to 8. To allow

the disabling of alarms to be controlled through the privileges associated with each users’ role, set

[Privilege] AckAlarms to 0.



56

Figure 41: Disabling an alarm

Similarly to acknowledging an alarm, if the currently logged in user, does not have the correct

privilege for that alarm, the disabled item in the pop-up menu will be disabled. Again, regardless

of the alarms configured area and privilege, and the value of the parameter [Privilege]

DisabledAlarms, alarms cannot be disabled if no user is logged into Vijeo Citect. Once an alarm

has been disabled, the alarm will no longer appear on the active alarm page.

The current list of disabled alarms can be seen by displaying the “Disabled” Page. Alarms can be

re-enabled by right clicking the alarm on the disabled page and selecting “Enable”.

The count of all unacknowledged alarms is displayed next to the alarm icon in the bottom left

hand corner of graphics pages that have been configured using templates from the tab style

include project.

Figure 42: Active Alarm Count

If the system also contains disabled alarms, the count of disabled alarms will be shown next to

the disabled alarm icon.



57

Figure 43: Disabled Alarm Count

Any genies that have been configured to use the AlarmCount() cicode function will also display

the count of alarms.

Figure 44: Using alarm counts in genies

5.3. Comments and user events

Comments can be added to any event on the SOE page, apart from other comments. To add a

comment, right click on the event that you want to add the comment to and select “Comment”. To

add a comment, a user must have privileges 1 - 8. Once a comment has been added, it will

appear as a new record in the SOE list, with the “Tag”, “Time” and “Date” fields being inherited

from the event that the comment was added to. The “Classification” set to “Comment”. The

“Message” field will contain the comment that was added by the user.



58

Figure 45: Adding comments to an alarm

User events appear in the SOE list with the “Tag” field inherited from the event the user event was

added to, but the time will be set to the current time. The “Message” field will again contain the

details of the user event.



59

5.4. Using the alarm filter form

Figure 46: The alarm page

The tab style alarm page can be filtered by pressing “Set Filter”.

Figure 47: Selecting a simple filter rule

To use one of the simple filter rules that were added previously, select the rule and click “Add”

and then OK.



60

Figure 48: Selected filter rule

Figure 49: Filtered alarm page

Operators can tell that the alarm page is filtered by the text “Filter Applied” underneath the “Set

Filter” option.



61

5.5. Sorting

All alarm pages can be sorted by any configured field, simply by adding an additional column to

the alarm display. Additional columns can be added either by clicking “Add Column” or by right

clicking on a column.

Figure 50: Adding a column to the alarm page



62

Figure 51: Area column added to the alarm page



63

Once the column has been displayed, the data can be sorted by clicking on the name of the

column. Clicking on it again will reverse the sorting order.

Figure 52: The alarm page sorted by area



64

5.6. Alarm Equipment Page

The alarm equipment page displays the equipment hierarchy in a tree view which displays the

number of alarms for each piece of equipment. This can also be used to filter the alarm list.

Figure 53: The alarm equipment page



65

By expanding the tree view, the operator can quickly determine the source of problem areas.

Figure 54: The expanded equipment tree and a filtered alarm list



66

In addition to this, the alarm filter form can be displayed clicking “Action” and “Filter” from the

menu.

Figure 55: Using the alarm filter form on the alarm equipment page



67

5.7. Localization

In Vijeo Citect 2015, the language that is displayed at runtime can be selected by the operator

when logging in.

Figure 56: Language selection while logging in

Upon logging in, any strings that have been marked for translation will automatically be translated

into the language selected by the operator.

Figure 57: The alarm page translated into French



68

Figure 58: The alarm page translated into Simplified Chinese

5.8. Logging

The alarm server has two types of logging mechanisms that can be used to assist in turning the

performance of the alarm server. Alarm snapshot files are generated periodically and contain a

summary of various statistics from within the alarm server. DBSnapshot files can be a useful tool

in troubleshooting your alarm server. Snapshot logging is controlled by the following parameters:

[Debug] SnapshotEnable – enables snapshot logging. This is disabled by default

[Debug] SnapshotInterval – controls how frequently a snapshot is taken. This defaults

to 30 minutes.

[Debug] SnapshotFiles – controls how many snapshot files are generated.

DBLog files contain verbose information regarding the alarm server logging. This form of logging

should only be enabled when advised by support. Snapshot files and alarm log files are each

2MB in size. By default, snapshot and log files can be found in the directory “C:\Program

Data\Schneider Electric\Vijeo Citect 7.50\Logs\DBLog.Alarm.<Cluster name>.<Server

name>”.



69

Snapshot files can be used to tune the performance of your system. As mentioned in section

4.11, the performance of the SOE page can be improved by increasing the CacheSize. Cache

information can be found in the file DBSnapshot_nnn.log in the section titled “34. Historic

Historian”.

Figure 59: Cache Size statistics

In this example, my cache is 68.2% full and contains 217.16Mb of data. If the % Cache figure is

100% and you are experiencing slow SOE page display times, it is recommended that you

increase the CacheSize.

5.9. Viewing the Alarm Events History Report

The Reports Deployment Manager (RDM) contains several pre-packaged EEMUA alarm

management reports which are designed for viewing useful alarm statistics. In this TVDA the

Alarm Events History report will be covered in this section.

This report displays statistical history of alarm events over a period of time and allows of

comparison of two periods. A hierarchy can be used to report only on a subset of alarms in the

database. Below are the detailed steps of how to browse and view data using the

‘AlarmEventsHistory’ report.

1. In the RDM, expand the Report Packs node followed by Standard Report Pack sub node.

2. Expand the Alarm Management folder. This will list the available alarm reports bundled in the

RDM.



70

Figure 60: Alarm Management reports bundled in the RDM

3. Right click on AlarmEventsHistory Report Browse.

4. In the ReportViewer pane, the report input parameters will be displayed as shown in the

figure below.

Figure 61: AlarmEventsHistory report input parameters

5. In the Alarms hierarchy drop down menu, select Section 1.

6. In the Hierarchy level drop down, select Level#1.

7. In the Alarm nodes drop down select Area 1.

Assuming we a rendering a monthly comparison report:

8. Report type period sequence: Month by day.

9. Reference period: Current month.



71

10. Comparison period: Last month.

11. Click the View Report button. This will display Alarm Events History report showing detailed

alarm event statistics for both Reference and Comparison periods. The entire report can be

viewed in the exported PDF document in the Appendix.

OO 6 – Validation


72

6. Validation

6.1. SCADA Server resource usage

The hardware resource usage on the primary, standby SCADA servers and a display client were

measured on varying sized systems. This test was performed on 10000, 50000 and 100000 variable

tag systems. The second variable that affects the results of this test is the rate at which alarms are

generated in the system. This test was repeated on the 50000 tag system with alarms being

generated at the rate of one, ten and fifty alarms per operator per ten minutes. Vijeo Citect 2015

alarm servers were configured to use 64-bit mode during all validation testing.

Windows performance monitor was utilized to measure hardware usage. This tool was used to

measure % processor time and private bytes for each SCADA Process (which is named citect32.exe

and citect.exe). Tests were performed for a minimum of three hours.

For the control client process, CPU and memory usage measurements were taken as well with the

tab style active alarm page open. The side effect of the re-architecture of Vijeo Citect 2015 alarm

servers is that client memory usage is much lower than the previous version.

Figure 62: The Client process memory usage

The above figure shows that even on the 10K tag system, the average memory usage on the display

client is less than 200 Mb with a rate of 10 alarms per operator per ten minutes.

For systems small to medium sized systems (less than 50K tags), the average memory usage on the

display client is equal or less than 100Mb, even on the busiest of systems (rate of 50 alarms per

operator per ten minutes).

OO 6 – Validation


73

Figure 63: The Client process CPU usage

The CPU usage on a display client when an alarm page is opened will on average be between 5%

and 10% of one CPU. There is a small correlation between the speed at which alarms are triggered

and the client CPU Usage.

However, even on a small system of 10000 or a large one of 100000 tags generating a rate of 10

alarms every 10 minutes per operator, this still does not exceed 6% of one CPU.

The introduction of 64-bit alarm servers improves scalability (i.e. more clients can now be supported)

but uses more memory.

On the primary alarm server, the CPU and memory usage for the alarm server process are:

Figure 64: The alarm server memory usage

The average alarm server memory usage increases with the size of the project. On the largest test

system, the average memory usage of the alarm server was 2 Gb.

OO 6 – Validation


74

Figure 65: The alarm server CPU usage

When the alarm server is running in a steady state, the average CPU usage of the alarm server is

extremely low (less than 1% with a rate of 10 alarms every 10 minutes per operator). On a medium

test system (50K), the average CPU Usage of the busiest alarm server (rate of 50 alarms every 10

minutes per operator) doesn’t exceed 3% of one CPU.

OO 6 – Validation


75

6.2. Alarm burst performance

Alarm burst performance was measured by triggering a percentage of variable tags in all PAC’s in

the system and then measuring the amount of time that it took for the appropriate number of alarms

to be triggered on the SCADA server. This test was performed on the 10000, 50000 and 100000

variable tag systems. The result shown below is the average of the time from when the burst was

taken on the server to the time for alarm count was correctly updated on all display clients.

Figure 66: Alarm burst performance

All times below are measured in seconds.

Percentage of

tags in burst 10000 tags 50000 tags 100000 tags

10% 2.964 4.012 5.540

30% 3.079 4.831 6.415

60% 5.665 6.626 8.883

Table 17: Alarm burst performance results in seconds

Alarm burst performance on a client is affected by the total number of alarms that have ever been

triggered on that client. After each new user logs in, the first time that an alarm page, or a page with

an alarm banner is displayed, that client requests some basic field information about all configured

alarms. This information is then cached in memory on the client. Subsequently, after a new alarm is

triggered on the client, the client will retrieve all of the remaining field information for that alarm and

store it in the cache. This means that alarm clients will be more responsive after every alarm in the

system has been displayed at least once. In these final set of alarm burst results, the alarm burst time

was measured when the burst was triggered for the first time, and this was compared against the

results after all alarms have been triggered at least once.

OO 6 – Validation


76

6.3. Alarm Page Display Performance

Alarm page display performance was measured by displaying the alarm page, and measuring the

time taken for alarms to be displayed on the page. As with previous tests, this test was performed

against 10 000, 50 000 and 100 000 tag systems. This time was measured on clients. The time to

apply a filter and to sort the alarm page was also measured in a similar manner. All times below are

measured in seconds.

Figure 67: Page display, sorting and filtering performance

Project size (tags) 10000 50000 100000

Alarm Page display time (s) 0.6 0.6 0.7

Alarm Filter time (s) 0.2 0.2 0.4

Alarm sort time (s) 0.1 0.1 0.3

Table 18: Page display, sorting and filtering performance results

The alarm page display tests were repeated on each of the three systems above, starting with one

client, and increasing the number of clients until the maximum number of clients, as described in

Table 1, was reached.

These show that the alarm page display times are not based on the system size, and will not increase

as the number of client’s increases. Page display times fluctuate between 0.1 and 0.7 second, with

an average across all test runs of 0.6 second.

OO 6 – Validation


77

6.4. SOE Page Display Performance

The performance of the SOE page was measured by displaying the page and measuring the amount

of time before a record is displayed. The performance of the SOE page is tied to the total number of

records that are read from the event journal.

For information Vijeo Citect 2015 sorting option on the SOE page has been disabled, unless the page

has a time based filter applied to it.

The SOE performance testing was performed only on the 50000 tag system with 4 clients attached,

but the number of events in the SOE list was varied, so that the total number of events in the event

journal would represent one days’ worth of data for a system running at one, ten and fifty alarms per

ten minutes per operator. Tests were done after 24 hours for each rate.

Change Rate Events triggered (in 24h) SOE (s)

1 1728 0.718

10 17280 0.788

50 84600 1.099

Table 19: SOE Page Display Performance after Events triggered for 24 hours.

The SOE page display performances are around 1 second to display the content in Vijeo Citect

2015. For details of the computer specifications use, please refer to the appendix.

Alarm bursts were performed to measure SOE page display performance after a huge number of

alarms triggered in a short time (less than 7 seconds).

Burst (% of tags) Events triggered SOE (s)

5% 2500 5.003

30% 15000 12.309

60% 30000 26.281

Table 20: SOE Page Display Performance after alarm burst.

The SOE page display performances are more than 25 seconds to display the content of 30K

event alarms in Vijeo Citect 2015.

O 7 – Conclusion


78

7. Conclusion

The management of alarms is one of the more crucial activities that an operator will need to

perform on a daily basis. Vijeo Citect 2015 contains equipment hierarchy and alarm features

that allow users to build systems that will allow an operator to quickly identify and action high

priority alarms.

This TVDA demonstrates that by assigning alarms the correct priorities and by implementing an

equipment hierarchy, the user can make use of Vijeo Citect 2015’s alarming features to assist the

operator to manage the alarms within their control system. These features include:

Using the alarm count functionality to allow the operator to quickly identify problem areas

Using alarm count in conjunction with equipment support to add flashing warning icons

next to genies on graphics pages

Fast Alarm counts performance

Using the Alarm equipment to find alarms with a high number of alarms and quickly

filtering the alarm display

Adding commonly used alarm filters to the alarm filter form

Using the SOE page to identify the events that led up to a deviation from normal

operation

Running alarm server as a 64-bit process to improve performance on alarm management

A Light Client for CPU and memory usage

8 – Appendix


79

8. Appendix

8.1. Glossary

The following table describes the acronyms and defines the specific terms used in this document.

Term Description

Alarm banner A short list of the current active alarms in the system that is shown on all

alarm tab style graphics pages.

DFB Derived Function Block

Event A change in state of an alarm. Typically state changes include the ON,

OFF, ACK and DISABLED events.

SOE Sequence of events

PAC Programmable automation controller

CPU Central processing unit

TVDA Tested Validated Documented Architecture

DRI Driver runtime interface – A mechanism for Vijeo Citect drivers to

exchange data with other services and systems within the product.

LAN Local Area Network. Typically based on Ethernet technology.

OPC OLE for Process Control.

OFS OPC Factory Server.

Table 21: Glossary

8 – Appendix


80

8.2. Bill of Material and Software

The following table summarizes all of the selected hardware:

Description Reference Firmware or Software Version Function

Primary SCADA Server HP Z220 workstation Intel Core I7-3770 CPU @ 3.40 GHz SCADA

Standby SCADA Server HP Z220 workstation Intel Core I7-3770 CPU @ 3.40 GHz SCADA

Display Client 1 Dell Optiplex 760 Intel Core 2Duo CPU E7500

@2.93Ghz SCADA

Display Client 2 to 8 VMware vCloud Director vCloud 5.5 SCADA

SCADA Software Vijeo Citect 2015 v7.50 SCADA

SCADA Driver OFSOPC v2.05.34.00001 SCADA

Communications Software OFS v3.50 SP7 SCADA

Quantum PAC CPU 140 CPU 651 50 v3.1 PAC

PAC software Unity Pro XL V8.00 PAC Programming

PC Software Primary

Server

Windows Server 2008

R2 Standard NC Operating System

PC Software Standby

Server

Windows Server 2008

R2 Standard NC Operating System

Display Client 1 Windows 7 Enterprise SP1 Operating System

Table 22: Bill of material and software

8 – Appendix


81

8.3. Computer Specifications

The following table lists the specifications of the various computers that were used in the

validation process.

Computer Model Processor Memory Hard Disk speed

Dell OptiPlex 760

Intel ® Core™ 2 Duo CPU

E7500 @2.93 GHz (2

Logical Processors)

4GB 7200 RPM SATA

HP Z220 (1)

Intel ® Core ™ i7-3770

CPU @ 3.40 GHz

(8 Logical Processors)

16Gb 7200 RPM SATA

HP Z220 (2)

Intel ® Core ™ i7-3770

CPU @ 3.40 GHz

(8 Logical Processors)

16GB

SSD

Read 500Mb/s

Write 175Mb/s

Virtual Machine on

VCloud Director

Intel® Xeon ® CPU X5650

@ 2.67 GHZ (2

Processors)

4Gb -

Table 23: Computer Specifications

8.4. Reference Documents

The following table is a list of documents you might want to refer to when more details are

needed.

Document Title Reference

How can I manage alarms effectively in PlantStruxture TVDA Document

How Can I Assess Vijeo Historian Data Acquisition Performance TVDA Document

Vijeo Citect PC-Based Help N/A

Table 24: Reference documents

8.5. Performance Benchmark

Two benchmarking tools were employed to perform benchmarking tests on the PC hardware.

This is done with the intention to give users of this guide a comparison point, such that they can

8 – Appendix


82

perform similar benchmarking on their equipment and understand where bottlenecks in

performance may occur.

The following benchmarking software was used:

Windows System Assessment Tool (available with Windows 7)

Windows System Assessment Tool is a module of Microsoft Windows 7 which measures

various performance characteristics and capabilities of the hardware it is running on and reports

them as a Windows Experience Index (WEI) score, a number from 1.0 and 5.9 for Windows Vista

and from 1.0 and 7.9 for Windows 7. The WEI is due to increase its maximum score with future

updates. The WEI includes five sub scores: processor, memory, 2D graphics, 3D graphics, and

disk; the base score is equal to the lowest of the sub scores.

8.5.1. Dell OptiPlex 760 Windows Experience Index

Component Details Score

Processor Intel® Core ™ Duo CPU E7500 @ 2.93GHz 6.5

Memory (RAM) 4.00 GB 5.9

Graphics ATI Radeon HD 3450 (Microsoft Corporation WDDM 1.1) 4.0

Gaming Graphics 1982 MB total available graphics memory 5.5

Primary hard disk 84 GB Free (270 GB Total) 5.9

Table 25: Windows Experience Index (Determined by lowest sub score): 4.0

8.5.2. HP Z220 Windows Experience Index

The windows experience index feature is not available in Windows 2008 r2, so these metrics

cannot be calculated.

8 – Appendix


83

8.6. Alarm Event History Report

The alarm event history report that was generated in Section 5.10 Viewing the Alarm Events

History Report can be viewed below.

Figure 68: Alarm Event History Report

Vijeo Citect, Vijeo Historian, OFS, Unity Pro, Quantum are trademarks or registered trademarks of Schneider

Electric. Other trademarks used herein are the property of their respective owners.

Schneider Electric Industries SAS

Head Office

35, rue Joseph Monier

92506 Rueil-Malmaison Cedex

FRANCE

www.schneider-electric.com

Due to evolution of standards and equipment, characteristics indicated in texts and images in this document are binding only after confirmation by our

departments.

Print:

Version 2.00 – 09 2015