tested validated documented architecture modular
TRANSCRIPT
How Can I …
Manage alarms effectively in Vijeo Citect?
Tested Validated Documented Architecture
Modular automation system
Develop
your project
© 2015 Schneider Electric All Rights Reserved
© 2015 Schneider Electric All Rights Reserved
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.
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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.
Failure to follow these instructions can cause death, serious injury or equipment
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
© 2015 Schneider Electric All Rights Reserved
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.
Failure to follow these instructions can cause death, serious injury or equipment
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.
© 2015 Schneider Electric All Rights Reserved
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.
© 2015 Schneider Electric All Rights Reserved
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.
© 2015 Schneider Electric All Rights Reserved
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.
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
12
OOOOOOO 1 – Introduction
© 2015 Schneider Electric All Rights Reserved
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.
OOOOOOO 1 – Introduction
© 2015 Schneider Electric All Rights Reserved
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
OOOOOOO 1 – Introduction
© 2015 Schneider Electric All Rights Reserved
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.
OOOOOOO 1 – Introduction
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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.
OOOOOO 2 – Selection
© 2015 Schneider Electric All Rights Reserved
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
OOOOOO 2 – Selection
© 2015 Schneider Electric All Rights Reserved
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.
OOOOOO 2 – Selection
© 2015 Schneider Electric All Rights Reserved
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.
OOOOOO 2 – Selection
© 2015 Schneider Electric All Rights Reserved
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
OOOOOO 2 – Selection
© 2015 Schneider Electric All Rights Reserved
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
OOOOOO 2 – Selection
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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”.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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”
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
42
Citect.ini parameter Value
[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.
Citect.ini parameter Value
[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.
Citect.ini parameter Value
[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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
46
Citect.ini parameter Value
[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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
54
Figure 40: Showing selected alarms in the alarm tab
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
62
Figure 51: Area column added to the alarm page
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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>”.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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.
OOO 5 – Operation and Maintenance
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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
© 2015 Schneider Electric All Rights Reserved
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