How can I …
Implement a Hot Standby QEIO
Architecture?
Tested Validated Documented Architecture
High availability automation system
Develop
your project
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.
3
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.
WARNING
WARNING indicates a potentially hazardous situation which, if not avoided, can
result in death or serious injury.
CAUTION
CAUTIÓN indicates a potentially hazardous situation which, if not avoided, can
result in minor or moderate injury.
CAUTION
CAUTION, used without the safety alert symbol, indicates a potentially hazardous
situation which, if not avoided, can result in equipment damage.
PLEASE NOTE
Electrical equipment should be installed, operated, serviced, and maintained only by
qualified personnel. No responsibility is assumed by Schneider Electric for any
consequences arising out of the use of this material.
A qualified person is one who has skills and knowledge related to the construction,
operation and installation of electrical equipment, and has received safety training to
recognize and avoid the hazards involved.
4
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 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 start up 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.
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.
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
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.
5
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.
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.
6
This document is intended to describe how implement a Hot Standby system
using a Quantum Ethernet Remote I/O solution.
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.
7
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 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.
8
Table of Contents
1. Introduction.........................................................................11
1.1. Purpose ....................................................................................................................................... 11
1.2. Customer Challenges ................................................................................................................. 11
1.3. Prerequisites ............................................................................................................................... 11
1.4. Project Methodology ................................................................................................................... 13
1.5. Glossary ...................................................................................................................................... 14
2. Selection..............................................................................17
2.1. PAC Station ................................................................................................................................ 17
2.2. Network ....................................................................................................................................... 17
2.3. Hardware summary..................................................................................................................... 22
2.4. Software ...................................................................................................................................... 22
3. Design..................................................................................24
3.1. SCADA System ........................................................................................................................... 24
3.2. Quantum Hot Standby System ................................................................................................... 26
4. Configuration ......................................................................43
4.1. SCADA configuration .................................................................................................................. 43
4.2. Switches configuration ................................................................................................................ 45
4.3. PAC configuration ....................................................................................................................... 59
5. Implementation ...................................................................77
5.1. Monitoring Elements in the Primary Section ............................................................................... 77
5.2. Monitoring Elements in the Standby Section .............................................................................. 83
5.3. Switchover Management ............................................................................................................ 88
5.4. SCADA ........................................................................................................................................ 89
9
6. Validation ............................................................................94
6.1. Functional tests ........................................................................................................................... 94
6.2. Performance tests ..................................................................................................................... 107
7. Conclusion ........................................................................130
8. Appendix ...........................................................................132
8.1. SCADA configuration ................................................................................................................ 132
8.2. Performance tests chronograms ............................................................................................... 157
10
1-Introduction
1. Introduction
1.1. Purpose
The purpose of this document is to provide recommendations, guidelines and
examples on how to implement a high availability automation system using a
PlantStruxure system, which is based on a Quantum Ethernet I/O solution and a Vijeo
Citect SCADA system.
This guide focuses on the different ways to increase availability through redundancy
at various levels of an automation system, and proposes a methodology to implement
an efficient high availability automation system.
Each step in the implementation of this system – from selection to operation – is
broadly described and illustrated with examples. The solutions described in this TVDA
are fully part of the PlantStruxure control system.
Note: A System Technical Note entitled How can I increase the availability of a
system? detailing the theoretical basics of high availability has already been issued.
1.2. Customer Challenges
The challenges for customers in industries where availability and reliability are major
concerns include:
•
Providing a high level of availability and reliability
•
Having a short recovery following system
•
Fast switchover times
•
Multiple levels of redundancy ensuring maintainability
•
Providing a system with remote I/O management for large scale plants (as
needed by tunneling or mining industries, for example)
This TVDA suggests approaches to meet these challenges and highlights specific
areas which can benefit from using a PlantStruxure Control System.
1.3. Prerequisites
We recommend readers have a good knowledge of the following software:
•
Unity Pro
•
Vijeo Citect
11
1-Introduction
We also recommend readers become familiar with the STN How can I increase the
availability of a system? and have some knowledge of Schneider Electric’s Quantum
PACs.
Following is a short summary of the general principles of redundancy and its
application in an automation system. The following PlantStruxure architecture
illustrates an example of the different layers where redundancy can be implemented.
Control room
Data servers
Control network
PAC stations
Field network
Field devices
The diagram also represents a wide range of hardware setups, which demonstrates
the ability to achieve various levels of redundancy.
Note: The figure above does not correspond to the architecture of this document. It
simply helps to give understanding of the different components of a full architecture.
The availability of an automation system can be increased at different layers:
• SCADA system:
The SCADA system has to handle data acquisition, graphics, events, alarms, trends
and reports. SCADA server redundancy enhances the likelihood these services will
continue to operate without loss of data in the case of a system interruption. Different
software and hardware configurations allow different levels of availability.
12
1-Introduction
• Control network:
Well defined topology and management of the control network increase network
availability and reliability. This, in turn, makes communication between the SCADA
system and the PAC stations more reliable. Several network topologies and network
protocols are available to achieve the optimal level of availability and to fit the needs
of the entire system.
• PAC station:
Depending on your requirements in terms of I/O number and topology, you can
choose between a Quantum or a Premium Hot Standby PAC system. The type of
field network and I/O system (local or distributed) are also elements to consider
before selecting a PAC station.
• Field network:
Redundancy can also be applied to the field network. As was the case for the control
network, a well defined topology and management of the network increase field
network availability.
1.4. Project Methodology
This TVDA describes the project methodology and includes the following phases:
Selection, Design, Configuration, Implementation and Performance. This guide is
focused on the Quantum architecture with Ethernet I/O. Its features are described in
the Selection phase.
Beginning with process analysis and user requirements, we identify and develop
common functionalities for the selected architecture. These key functions are
explained in the Design, Configuration and Implementation phases.
Finally, the Performance phase summarizes the results of different tests performed
on the architecture.
The phases described in this document are:
Selection: in this phase the selection procedure to define a redundant architecture is
presented.
Design: this phase covers the operational principles of the different components of
high availability architecture:
•
SCADA system
•
Network
•
PAC station
13
1-Introduction
Configuration: in this phase the configuration information for the different components
of the architecture is detailed.
Implementation: using the same architecture and components, information is provided
about the final customization which was completed to address the project
requirements.
Validation: a summary of the architecture performance in response to simulated
events is presented in this phase.
1.5. Glossary
Term
Description
ART
Application Response Time – the delay between an event,
such as an input changing state or a commanded output, and
the system response to that event
Control network
The portion of the control system network where process data
is primarily transferred. It includes SCADA-to-PAC traffic and
functional-unit-PAC-to-functional-unit-PAC traffic
CRA
Quantum 140 CRA 312 00 Ethernet RIO adapter module
located in each RIO drop
CRP
Quantum 140 CRP 312 00 remote I/O scanner located in the
local rack
DIO
Distributed I/O – Ethernet-enabled devices which can include
Schneider Electric and/or third-party products
DRS
Dual-Ring Switch – a Schneider Electric ConneXium Ethernet
switch with the necessary configuration to support the ERIO
main ring, as well as a DIO or ERIO sub ring, and DIO clouds.
Other switching devices are not permitted in the ERIO network
ERIO
Ethernet Remote Input/Output – architecture where the I/Os
are deported on distant racks; the racks are connected to the
PAC using an Ethernet connection
Field network
The portion of the control system network in which field device
monitoring and control traffic is primarily transferred. It
includes PAC-to-I/O, PAC-to-drive traffic, and primary-PAC-tohot-standby-PAC traffic
14
1-Introduction
Term
Description
IU_ERIO
Immediate update I/O – a function block in Unity Pro which
allows you to schedule the reading of selected inputs or the
writing of selected outputs before the current logic scan is
complete. This function block must not be used in a hot
standby system.
NOE
Quantum140 NOE 771 xx Ethernet communication module
PAC
Programmable Automation Controller
Scan time
The time required to process the PAC user application logic
and execute all communication tasks associated with the scan
Quantum EIO
The Quantum Ethernet remote I/O solution
RIO
Remote I/O – I/O devices used when predictable deterministic
performance is expected
RPI
Requested Packet Interval – the amount of time between
packets of input data transmitted by a CRA, expressed in
milliseconds
15
1-Introduction
16
2-Selection
2. Selection
Depending on the level of availability required, redundancy is applied in various ways.
This section describes the various options available in terms of redundancy and
availability.
2.1. PAC Station
This TVDA is a guide for implementing high availability using Hot Standby
Quantum Ethernet I/O and Ethernet Remote I/O drops.
We chose to use the CPU reference 140 CPU 672 61 as it can address
applications with a distance of up to 10 kilometers between the two Hot
Standby CPUs. This is done via an optical single mode Ethernet port. In
addition, this CPU supports more memory, greater size and a higher speed
exchange capacity between the two Hot Standby CPUs.
2.2. Network
2.2.1. Network topologies
Various topologies and protocols are used to increase the availability of the network
(both control and field networks). The main idea is to create alternative paths to
access devices so when a network element on one path stops functioning another
path is used.
Ring topologies are mainly used to increase the level of network availability. Network
redundancy management protocols, such as RSTP or MRP, are used for network
recovery in case part of the network ceases to function.
Our project features two sub-networks:
•
A control network linking PACs and SCADA
•
A field network linking PACs, remote Ethernet I/O and other devices
Referring to the standard PlantStruxure architectures, we will work with Redundant
Flexible Distributed (RFD) and Redundant Compact Evolutive (RCE) architectures.
Redundant Compact Evolutive architecture
This architecture includes Ethernet remote I/Os.
17
2-Selection
Redundant Compact Evolutive architecture
PRIMARY
SERVER
STANDBY
SERVER
VIJEO CITECT
CLIENT
FIELD
NETWORK
RING 1 : 172.20.110.1
RING 2 : 172.20.120.1
Control RING 1
{
EIO SUB-RING 1
EIO SUB-RING 2
QUANTUM
REDUNDANCY LINK
RING 1 : 172.20.110.2
RING 2 : 172.20.120.2
SW1
Control RING 2
FIELD MAIN RING
SW2
172.20.110.201
172.20.110.202
SW5
SW4
COPPER CABLE
172.20.110.205
172.20.110.204
OPTICAL FIBER
SW6
172.20.110.206
SW3
172.20.110.203
CRP
NOE3
NOE2
NOE 1 : 172.20.110.111
NOE 2 : 172.20.120.121
NOE 3 : 172.20.130.131
CRP : 172.20.130.1
NOE1
CRP
NOE3
NOE2
NOE1
Distant devices
NOE 1 : 172.20.110.110
NOE 2 : 172.20.120.120
NOE 3 : 172.20.130.130
CRP : 172.20.130.2
STANDBY QUANTUM
PRIMARY QUANTUM
SW8
SW7
172.20.130.208
172.20.130.207
C15
C15
SW12
SW11
172.20.130.212
172.20.130.211
C5
C5
DROP 4
DROP 1
CRA : 172.20.130.6
CRA
CRA
CRA : 172.20.130.3
DROP 5
DROP 2
CRA : 172.20.130.4
CRA
CRA
CRA : 172.20.130.7
DROP 6
DROP 3
CRA : 172.20.130.8
CRA
CRA
CRA : 172.20.130.5
Note: In most chapters of this TVDA, this architecture will not be detailed; if you need to implement it,
please ignore the sections about DIO clouds and NOE3. We will verify hereafter that DIO clouds do
not impact EIO performance and determinism.
Redundant Flexible Distributed architecture
This architecture includes Ethernet remote I/Os and Distributed I/O clouds.
Note: On the figure on the next page, the DIO and Ethernet remote I/Os sub-rings are
represented in different colors, but they are in the same network.
18
2-Selection
Redundant Flexible Distributed architecture
PRIMARY
SERVER
STANDBY
SERVER
VIJEO CITECT
CLIENT
RING 1 : 172.20.110.1
RING 2 : 172.20.120.1
FIELD
NETWORK
RING 1 : 172.20.110.2
RING 2 : 172.20.120.2
SW1
SW2
172.20.110.201
172.20.110.202
{
SW5
SW4
Control RING 1
Control RING 2
FIELD MAIN RING
EIO SUB-RING 1
EIO SUB-RING 2
DIO CLOUD 1
DIO CLOUD 2
QUANTUM
REDUNDANCY LINK
172.20.110.205
172.20.110.204
SW6
172.20.110.206
COPPER CABLE
SW3
172.20.110.203
OPTICAL FIBER
CRP
NOE3
CRP : 172.20.130.1
NOE2
NOE 1 : 172.20.110.111
NOE 2 : 172.20.120.121
NOE 3 : 172.20.130.131
NOE1
CRP
NOE3
NOE1
NOE2
Distant devices
NOE 1 : 172.20.110.110
NOE 2 : 172.20.120.120
NOE 3 : 172.20.130.130
CRP : 172.20.130.2
STANDBY QUANTUM
PRIMARY QUANTUM
SW8
SW7
172.20.130.208
172.20.130.207
C15
C15
172.20.130.212
172.20.130.211
ATV71
172.20.130.50
STB
172.20.130.55
SW12
SW11
STB
172.20.130.54
STB
172.20.130.64
C5
C5
ATV71
172.20.130.60
SW9
CRA : 172.20.130.6
SW10
CRA
CRA
CRA : 172.20.130.3
172.20.130.209
STB
172.20.130.65
DROP 4
DROP 1
172.20.130.210
CRA : 172.20.130.4
CRA : 172.20.130.7
CRA
STB
172.20.130.51
STB
172.20.130.58
CRA : 172.20.130.5
CRA : 172.20.130.8
CRA
CRA
TESYS T
172.20.130.62
DROP 6
DROP 3
TESYS T
172.20.130.52
STB
172.20.130.67
STB
172.20.130.61
TESYS U
STB
172.20.130.57
STB
172.20.130.66
DROP 5
DROP 2
CRA
STB
172.20.130.56
TESYS U
STB
172.20.130.68
19
2-Selection
2.2.2. Network management hardware
In our architecture, we use multiple Ethernet switch type, each of which is part of the
Schneider Electric ConneXium Ethernet product line.
Copper only switches
The switches SW1, SW3, SW4, SW5, SW9 and SW10 use only Ethernet
connections. Depending on the number of necessary ports, the following switches
could be used:
•
TCSESM083F23F0 (eight ports)
•
TCSESM043F23F0 (four ports)
Note: We only use the eight port reference.
Copper and optical fiber switches
If the remote devices need to be more than two kilometers away from the control
room, then the optical fiber should be single mode. In this case there should also be
some additional switches, as seen on the figure below:
SW2
SW6
< 10 km
CRP
NOE3
NOE2
NOE1
Distant devices
The best choice for these switches would be the following references (Ethernet switch
SW2 needs an extra port for a SCADA server, the others do not):
20
2-Selection
•
TCSESM083F2CS0 (six Ethernet ports, two optical fiber ports)
•
TCSESM043F2CS0 (two Ethernet ports, two optical fiber ports)
In our lab, we used the TCSESM083F2CU0 Ethernet switch, which has six
Ethernet ports and two optical fiber ports. This switch cannot manage single
mode optical fiber, only multi mode. The drawback is that the optical fiber
length cannot exceed two kilometers in multi mode; however it can be up to
ten kilometers in single mode. The 140NOE Quantum module can manage
directly multi mode optical fiber, minimizing the number of Ethernet switches
on the dual control ring.
SW2
SW6
< 2 km
CRP
NOE3
NOE2
NOE1
Distant devices
Extended Ethernet optical fiber switches (DRS)
For the main Ethernet I/O network ring we need ConneXium switches
with extended capabilities as they must be able to manage the drops
sub-rings. Therefore, we need the ConneXium switches to manage
two RSTP rings and they must have optical fiber ports.
The corresponding reference is TCSESM063F2CS1. It has six
Ethernet ports and two single mode optical fiber ports.
21
2-Selection
2.3. Hardware summary
The following table summarizes all of the selected hardware:
Designation
Parts
Reference
Firmware version
Quantum racks
Modicon Quantum 6-slot rack
10-slot rack
Quantum PAC units
Power supply
CPU
NOE
CRP
Quantum Ethernet Remote I/O modules (drops)
CRA
Digital input module
Digital outnput module
CPS 124 20
140 CPU 672 61
140 NOE 771 11
140 CRP 312 00
8 Ethernet ports
Ethernet switches 6 Ethernet ports, 2 multi mode optical fiber ports
6 Ethernet ports, 2 single mode optical fiber ports, extended (DRS)
TCS ESM 083F23F0 V5.00
TCS ESM 083F2CU0 V5.00
TCS ESM 063F2CS1 V6.00
Power distribution module
DIO clouds (STB) Ethernet Modbus TCP/IP, dual port
Digital input module
Digital outnput module
STB PDT 3100
STB NIP 2311
STB DDI 3230
STB DDO 3200
140 XBP 006 00
140 XBP 010 00
140 CRA 312 00
140 DDI 353 00
140 DDO 353 00
COPRO: 3.0 IR27 - OS: 3.0 IR41
OS: V5.00 IE46
OS: V1.07 IE0x03
OS: V1.06 IR05
2.4. Software
We use the following software:
•
Unity Pro V6.0
•
Vijeo Citect V7.20 SP1
•
Advantys V5.5.0.0
•
OFS V3.35
22
2-Selection
23
3-Design
3. Design
This chapter covers the operational principles of the different components of a high
availability architecture. We will review the SCADA setup, and then the following
points concerning the PAC station:
• What is a Hot Standby System
• Parts and tools of a Hot Standby System
• Specifications and constraints of a Hot Standby System
We will also describe the derived function blocks (DFBs) used in our Hot Standby
library and why they have been developed.
The SCADA and network parts are detailed further in the Configuration chapter.
3.1. SCADA System
The main operating principles of the different SCADA servers are described in the
following sections.
3.1.1. General principles
The different servers of the SCADA system (Alarm, Report, Trends and I/O servers)
can either be installed on the same computer or on different computers, which
provides increased reliability. For a redundant configuration, each server (primary) is
associated with its redundant server (standby) installed on a different computer.
For example, the picture below describes servers installed on redundant computers
(primary and standby):
Redundant System Servers
Reports
Reports
Trends
Trends
Alarms
Alarms
I/O
I/O
Primary
Standby
24
3-Design
3.1.2. I/O Server redundancy
In a redundant SCADA system an I/O device is associated with both the primary and
standby servers. The primary server periodically accesses the I/O device to read and
write tags. The Standby server only checks the communication with the I/O Device.
At startup, if the primary I/O server can not establish a connection with the I/O device,
the SCADA system switches to the standby I/O server. During operation, if the
primary I/O server stops communicating with the I/O devices, the system then
switches to the standby I/O server. The following diagrams illustrate two cases –
firstly a broken network cable, and secondly a server that has stopped
communicating.
Client
PRIMARY
IO
SERVER
Client
STANDBY
IO
SERVER
Client
Client
PRIMARY
IO
SERVER
STANDBY
IO
SERVER
When the I/O server defined as primary returns to operational state, the SCADA
system returns control back to the primary server.
3.1.3. Alarms/Trends/Reports Servers (ATR) redundancy
The management of the Alarms, Trends and Report servers (ATR) by the SCADA
system follows the steps below:
•
If the primary ATR server stops operating, the system switches to the
Standby ATR server
•
When the ATR server defined as primary returns to operational state, any
clients connected to the standby ATR server remain connected to the
standby server
The following picture shows a server
Redundant System Servers
reconfiguration initiated by a switchover:
the I/O, trends and reports servers are
working on the primary SCADA server,
and the alarms server is working on
standby SCADA server.
Standby
Standby
Primary
Standby
Primary
Primary
Standby
Primary
Primary
Standby
25
3-Design
3.2. Quantum Hot Standby System
This section describes the different features and specifications of a redundant
Quantum PAC system.
3.2.1. Hot Standby Definition
A Hot Standby system is used when process downtime cannot be tolerated. A Hot
Standby system delivers high availability through redundancy, and always consists of
two units with identical configurations. One of the two units acts as the Primary CPU
controller, and the other acts as the Standby CPU controller. One controller must be
set in the primary CPU state and the other must be in the standby CPU state, or
offline. The redundant unit takes over control when the main unit is faulty or powered
down.
The primary PAC updates inputs, manages hot standby, runs the program while
transferring data to the standby PAC and updates outputs. Thus, the switchover
between the primary and the standby PACs occurs without any loss of data.
As described in the diagrams below, for each execution cycle the outputs update only
takes place when the data transfer and the program execution are completed.
Therefore, it is important to properly define the amount of data to be transferred from
the primary to the standby PAC in order to minimize the wait time induced by a data
transfer that takes longer than the execution of the program.
26
3-Design
Hotstandby CPU
Primary CPU
MAST task
Copro task
Copro task
Input
Input
1 MAST task cycle
HSBY
copy
User logic
Data
transfer
Section 0
Section 1
.
.
.
MAST task
7 ms per
100 kB
copy
HSBY
Data
transfer
User logic
Section 0
17 ms per
100 kB
Section n
Output
Output
Example 1: Data transfer is optimized
In the diagram below the cycle execution is optimized – the data transfer (100 kB) is
performed faster than the program execution.
27
3-Design
Primary CPU
MAST task
80 ms
Hotstandby CPU
Copro task
Copro task
Input
1 MAST task cycle = 87 ms
HSBY
User logic
Section 0
Section 1
.
.
.
MAST task
80 ms
Input
Copy
7 ms
Copy
100 kB
100 kB
Data
transfer
Data
transfer
17 ms
100 kB
100 kB
Wait
Wait
Copy
100 kB
User logic
Section 0
Section n
Output
Output
The total time here is 87 milliseconds (ms) because the input and output times are
included in the configured MAST cycle time (80 ms); the extra seven milliseconds
come from the hot standby data copy from the main processor to the coprocessor.
Example 2: Data transfer slows down the system
In the diagram below the larger data transfer (600 kB) causes a wait time that slows
down the cycle execution.
28
3-Design
Primary CPU
MAST task
80 ms
Hotstandby CPU
Copro task
Copro task
Input
1 MAST task cycle > 144 ms
HSBY
User logic
Section 0
MAST task
80 ms
Input
Copy
42 ms
Copy
600 kB
600 kB
Data
transfer
Data
transfer
600 kB
600 kB
Section 1
.
.
.
HSBY
User logic
Section 0
102 ms
Section n
Wait
Wait
Output
Output
The total time here is more than 144 ms (data copy of 42 ms and data transfer of 102
ms) because the input and output times must be added (in the previous example they
were included in the MAST task cycle time).
Influence of the data exchanges
In this section we consider the influence of the hot standby data exchanges according
to the previously described behavior of a Quantum hot standby system.
The data adds the following time:

7 ms per 100 kB every cycle

17 ms per 100 kB in parallel to the user logic
The below graph shows the coprocessor copy time, the coprocessor process time
and the total time when both are combined:
29
3-Design
240
220
200
180
time (ms)
160
140
120
100
80
60
40
20
0
100
200
300
400
500
600
700
800
data (kB)
900
1000
copro copy time
copro process time
total time
Following is an example of how to use this graph – if we have a standalone system
running cyclically, solving the user logic in 140 ms with 400 kB of data, we can see
that the same system running in hot standby will have:

28 ms extra time because of the data transfer to the copro (green curve,
copro copy time)

No extra time due to data transfer to the hot standby Quantum because the
copro process time (blue curve) reaches 68 ms for 400 kB, which is smaller
than 140 ms
Therefore, the total cycle time for this system would be 168 ms.
The same system with 900 kB of data would have:

63 ms extra time because of the data transfer to the copro (green curve,
copro copy time)

13 ms extra time due to data transfer to the hot standby Quantum because
the copro process time (blue curve) reaches 153 ms for 900 kB, which is
greater than 140 ms
Note: these two examples were presented assuming the input and output processes
have very short times. For an accurate calculation, at least 2 ms per drop should be
added.
30
3-Design
Switchover Conditions
A Hot Standby system is designed to provide uninterrupted service. This feature
requires continuous monitoring of different devices.
Note: When working with Quantum PACs the switchover is performed only if the
standby PAC is operational and ready to take over control from the primary PAC.
A Hot Standby system continuously monitors the key components in order to detect
any stoppage in operation. Additional monitoring is performed by the application for
more specific requirements.
Monitoring by the Hot Standby system initiates a switchover when the following
events occur:

Power supply is down

CPU error (firmware, hardware)

Halt, Stop, Offline CPU

CRP module error
For the Quantum Hot Standby architectures presented in this guide additional
equipment (network controller and device network) is monitored by the application in
order to increase the availability.
To perform this specific monitoring, we need to develop Derived Function Blocks
(DFBs) that can:
•
Monitor the system
•
Control and process the anomalies
•
Handle the switchover
3.2.2. DFB Libraries
The Unity Pro Quantum system library offers Elementary Function Blocks (EFBs) to
manage a Hot Standby system. These EFBs allow the handling of command
(%SW60), status (%SW61) and reverse (%SW62 to 65) registers.
Network monitoring is integrated into our architectures. However, this functionality is
not handled intrinsically or by any standard function block, therefore we developed a
specific Hot Standby DFB library named NOE_Monitor.
We have developed an events synthesis block that processes the output of the
instances of this DFB, while offering the possibility to mask some anomalies, and a
31
3-Design
switchover management block which controls the availability of the Standby PAC
before initiating a switchover.
Primary and Standby PACs
The primary PAC runs the application program, including the first section. It handles
remote I/Os and updates the redundant PAC after each program cycle. If the primary
PAC stops, then the standby PAC takes over the control from the primary PAC.
The standby PAC only runs the first section of the application program, and checks
the availability of the CPU and CRP modules, but does not handle remote I/Os.
This document focuses on remote I/Os, which means local I/Os are not covered in
this TVDA. Please refer to the Quantum Hot Standby system user manual for more
details on this topic.
CAUTION
RISK OF EQUIPMENT DAMAGE
Local output values on a hot standby system are not synchronized. Read the
Quantum hot standby system user manual for local I/Os management.
Failure to follow these instructions can result in equipment damage.
QUANTUM
PAC_A
MAC Add:
00.00.54.18.59.49
PAC_B
MAC Add:
00.00.54.18.65.BF
Assuming that the configuration of the system is correct, the first PAC to be powered
up is automatically recognized as the primary PAC. Therefore, you can define the
PACs roles by controlling the order in which they are powered up.
When two redundant CPU PACs are switched on simultaneously, the firmware
automatically affects the primary status according to the MAC address. The PAC with
the lower MAC address is defined as PAC A (which is the primary PAC) when the
system is powered up.
32
3-Design
Software Constraints
As mentioned in the Hot Standby system user manual, the following programming
methods are examples which must NOT be used in a Hot Standby application:
•
Preemptive, asynchronous, or interrupt-driven (EVENT) tasks
•
FAST tasks
•
Events and edge triggers, and so on
•
IU_ERIO function block
We do not recommend using TIMER events as they are not synchronized in Quantum
Hot Standby applications.
WARNING
UNINTENDED EQUIPMENT OPERATION
Do not use programming methods based on data that are not synchronized
in each MAST task cycle.
Failure to follow these instructions can result in death, serious injury,
or equipment damage.
WARNING
UNINTENDED EQUIPMENT OPERATION
Do not use the IU_ERIO function block in Quantum Hot Standby installations.
Failure to follow these instructions can result in death, serious injury, or
equipment damage.
3.2.3. Hot Standby System Programming Elements
This sub-section describes programming basics which may be useful when
implementing a Hot Standby system.
System Words
 %SW60: Command Register
The command register defines the operating parameters of a Hot Standby application
for both the primary and standby CPUs.
The system word %SW60 can be used to read and write the command register of a
Hot Standby system. The diagram below illustrates the Quantum system word
%SW60:
33
3-Design
 %SW61: Status Register
The Hot Standby Status Register is a readable register located at system word
%SW61 and is used to monitor the current status of the primary and standby CPUs.
The following diagram illustrates the Quantum system word %SW61:
%SW62…65: Reverse Register
34
3-Design
System Words %SW62/63/64/65 are reverse registers reserved for the reverse
transfer process. The reverse registers can be written in the application program (first
section) of the standby CPU controller and are transferred at each scan to the primary
CPU controller.
Non-transfer area
The non transfer area is a defined memory zone which is not transferred during the
update of the standby CPU controller. The size of the Quantum PAC zone is defined
by the user (%MW1 to %MWx).
First Section (section 0)
In a PAC redundancy system, the execution of the application program differs
depending on the PAC in which the execution takes place. The main difference is that
the whole application program is executed in the primary PAC, whereas the standby
PAC only executes the first section (section 0). This point is very important as many
settings of the system are defined in section 0.
3.2.4. Quantum Hot Standby DFBs Library
The system automatically performs a switchover in some cases (see section 3.2.1. ).
The NOE modules failure and network loss on the NOE modules are not managed by
the system because the expected behavior can be different for different projects.
The following table summarizes the different DFBs created for the Quantum
application in this TVDA. These DFBs allow the application to monitor networks and
NOE modules, and to manage applicative switchovers.
ETHERNET
PROFIBUS
SYNTHESIS
SWITCHOVER
DFB
NOE_MONITOR
PTQ_MONITOR
SYNTH_FAULT
SYNTH_OR_NOE
SYNTH_AND_NOE
SYNTH_OR_PTQ
SYNTH_AND_PTQ
SWITCH_MANG
FUNCTION
Monitoring NOE Ethernet Module
Monitoring PTQ Ethernet Module
Synthesis Fault monitored elements
Synthesis Fault NOE module (Logic OR)
Synthesis Fault NOE module (Logic AND)
Synthesis Fault PTQ module (Logic OR)
Synthesis Fault PTQ module (Logic AND)
Switchover Management
Note: The PTQ (Profibus) functions are not used in this document.
Ethernet link monitoring DFBs
NOE_Monitor
The NOE_Monitor DFB monitors the Ethernet link hosted by the NOE module.
35
3-Design
NOE_Monit or
BOOL
BOOL
BOOL
INT
INT
MSTR_ACTIVE
MSTR_DONE
MSTR_ERROR
RateEt
Error_Count
MSTR_ACTIVE
MSTR_DONE
MSTR_ERROR
RateEt
Error_Count
BOOL
BOOL
BOOL
INT
INT
ARRAY[0..9]OF INT
MSTR_Control
MSTR_Control
MSTR_DataBuf
ARRAY[1..9]OF INT
ARRAY[1..37]OF WORD
BYTE
INT
INT
BOOL
Slot
MonitoringRate
Retries
Pulse
Data_TCP
LED_APPL
LED_LINK
LED_RUN
NOE_Failure
CFG_PORT
ETH_100M
OPTICFIB
FULL_DUP
DUP_ADD
FAULT
EQUP_TYP
IP_AD_1
IP_AD_2
IP_AD_3
IP_AD_4
MAC_ADD_1
MAC_ADD_2
MAC_ADD_3
MAC_ADD_4
MAC_ADD_5
MAC_ADD_6
DIAG_TCP
BOOL
BOOL
BOOL
BOOL
BOOL
BOOL
BOOL
BOOL
BOOL
BOOL
UINT
INT
INT
INT
INT
WORD
WORD
WORD
WORD
WORD
WORD
The monitoring is managed by the MBP_MSTR block function integrated in the NOE_Monitor DFB.
The MBP_MSTR block allows operations to be performed on communication networks such as the
extraction of the local statistics of the NOE module.
MBP_MSTR
ENABLE
ACTIVE
ABORT
ERROR
SUCCESS
CONTROL
DATABUF
The extraction rate is controlled by the ‘Monitor Rate’ parameter configured by the user. Extracted
data is available on output pins, as shown in the diagram above.
36
3-Design
NOE Local Statistics
In order to diagnose the status of the NOE module, we need to check the status of
the module and the link with the Led RUN and Led Link respectively. The number of
faults is given by the MPB_MSTR. This number is compared to the ‘retries’ value. If
the number of faults is greater than or equal to the retries value, then the
NOE_Failure is set to 1.
37
3-Design
The block implementation is associated to a data structure NOE_Monit.
NOE_Monit
MSTR_Active
+
MSTR_Done
MSTR_Error
MSTR_RateEt
MSTR_Error_Count
Failure
Fault
Led_Appl
Led_Cfg_Port
Led_Eth_100M
Led_Full_Dup
Led_Link
Led_Ooptic_Fib
Led_Run
DUP_ADD
EQUP_TYP
MAC_ADD_1
MAC_ADD_2
MAC_ADD_3
MAC_ADD_4
MAC_ADD_5
MAC_ADD_6
IP_AD_1
IP_AD_2
IP_AD_3
IP_AD_4
EQUIP_TYPE
+
MSTR_Control
+
MSTR_DataBuf
+
MSTR_Data
St ruct
BOOL
BOOL
BOOL
INT
INT
BOOL
BOOL
BOOL
BOOL
BOOL
BOOL
BOOL
BOOL
BOOL
BOOL
BOOL
WORD
WORD
WORD
WORD
WORD
WORD
INT
INT
INT
INT
UINT
ARRAY[1..9] OF INT
ARRAY[0..37] OF WORD
Diag_TCP
One block is required per NOE module.
Switchover Management
Anomalies Synthesis
SYNTH_FAULT
Synthesis Fault NOE Module
Synthesis Fault PTQ module
Synthesis Fault SCADA
Fault Mask word
BOOL
BOOL
BOOL
WORD
Faulty_NOE
Faulty_PTQ
Faulty_SCADA
Fault_Mask
Fault_Synth
Fault
INT
BOOL
Synthesis Fault Word
Fault
This block processes the faults that should trigger a switchover. We find in inputs the
results of the NOE and PTQ (not used in this document) modules failure detection.
38
3-Design
‘Faulty_SCADA’ is an input pin used when the communication between the SCADA
system and the PAC is monitored.
This DFB also processes:
• Battery events

%S67 = application memory card battery

%S68 = processor battery

%S75 = data storage memory card battery
• CPU non-operating

%S12 = CPU running
• General in-rack I/O non-operating

%S119 = event of one or several I/O modules in the rack
• Slots 3 to 10 non-operating

%SW180 = operating status of Quantum modules installed on station 1
The faults processing is performed using the mask value set on the input pin
‘Fault_Mask’. This mask allows us to select which event to take into account,
depending on the configuration and the user’s settings.
Each exception corresponds to a single bit of the ‘Fault_Synthesis’ word:
BIT
Element monitored
Bit 0
Bit 1
Bit 2
Bit 3
Bit 4
Bit 5
Bit 6
Bit 7
Bit 8
Bit 9
Bit 10
Bit 11
Bit 12
Bit 13
Battery Exception
CPU Exception
General In-Rack I/O Exception
Exception on Slot 3
Exception on Slot 4
Exception on Slot 5
Exception on Slot 6
Exception on Slot 7
Exception on Slot 8
Exception on Slot 9
Exception on Slot 10
Ethernet Adapter(s) NOE Exception
PROFIBUS Adapter(s) PTQ Exception
SCADA Exception
The result of this synthesis is saved in a word and set as an output on the
‘Fault_Synth_Plc’ pin. If there is at least one exception response, the output pin ‘Fault’
is set to one.
39
3-Design
During the implementation of the system this block is used twice – once for the
primary PAC and once for the standby PAC.
In order to be able to compute the status of several NOE or PTQ modules logical ‘OR’
and ‘AND’ processing DFBs have been created:
SYNTH_AND_NOE
BOOL
BOOL
BOOL
BOOL
BOOL
BOOL
FLT_NOE_1
FLT_NOE_2
FLT_NOE_3
FLT_NOE_4
FLT_NOE_5
FLT_NOE_6
SYNTH_OR_NOE
BOOL
FAULT_NOE
BOOL
BOOL
BOOL
BOOL
BOOL
BOOL
FLT_NOE_1
FLT_NOE_2
FLT_NOE_3
FLT_NOE_4
FLT_NOE_5
FLT_NOE_6
FAULT_NOE
Switchover Management
SWITCH_MANAG
Synthesis Fault word Primary
Synthesis Fault word Standby
Switchover Number Reset
Manual Switchover
INT
INT
BOOL
BOOL
PRIM_DIAG
STBY_DIAG
SWITCH_NB_Reset
FORCE
SWITCH_NB
FORCE
UNIT
BOOL
Switchover request
Manual Switchover
The ‘Switch_Manag’ DFB manages and counts switchover queries. The switchover
approval is computed from the primary and standby PACs, with diagnoses coming
from the ‘Fault_Synthesis’ DFBs, as illustrated above.
A switchover is allowed if:
• The standby PAC diagnosis is correct
• More than 30 seconds have elapsed since last switchover
Note: The time delay before the switchover takes place can be adjusted using
variables of the DFB (Delay_Time_Before_Switchover). This delay is set to one
second by default.
The switchover counter can be reset using the input pin ‘Switch_N_Reset’.
For maintenance reasons the input pin ‘FORCE’ allows a manual switchover of the
system.
During the implementation of a Quantum Hot Standby system this block is only used
once.
40
BOOL
3-Design
Ethernet I/Os
The use of Ethernet I/Os in a Hot Standby system allows correspondence with
redundant I/Os. It is important to configure the ‘drop hold up time’ according to the
cycle time and the application. This parameter is the time during which I/O values are
maintained while a switchover occurs.
The Ethernet I/O stations are monitored using the following system words:
System Bits/Words
Symbol
Description
%S117
ERIOERR
Detected remote I/O error on the Ethernet
I/O network
%SW101
ERIO_ CCOTF_COUNT
ERIO CCOTF counting status register
%SW108
FORCED_DISCRETE_COUNT
Forced bit counting status register
%SW109
FORCED_ANALOG_COUNT
Forced bit counting status register
%SW152 ... %SW153
ERIO_DROP_ERROR
Detected Ethernet remote I/O drop error
status register
%SW172 ... %SW173
ERIO_CONNECT_STATUS
Ethernet I/O communication health status
for drops in standalone and primary
systems
%SW176 ... %SW177
SDBY_ERIO_CONNECT_STATUS
Ethernet I/O communication health status
for drops in standby systems
%SW180 ... %SW181
IOHEALTHij
%SW182 ... %SW183
(i = 1 ... 32, j = 1 ... 5)
%SW641 ... %SW702
ERIO_MOD_HEALTH
Health bits of the PLC modules (including
Hot Standby CPUs)
Ethernet remote I/O module health bit
status
41
3-Design
42
4-Configuration
4. Configuration
The configuration of the different components of our high availability system is
described in this chapter. First, the configuration of the redundant SCADA system,
using OFS communication protocols, is detailed. Next, we describe the setup of the
Quantum Hot Standby CPUs and corresponding modules. Then the Ethernet
configuration is addressed with particular reference to the configuration of the
manageable Ethernet switches, the main components of the control and field
networks.
4.1. SCADA configuration
The configuration of the SCADA system creates the various SCADA servers, taking
into account the network topology.
PRIMARY
SERVER
STANDBY
SERVER
VIJEO CITECT
CLIENT
A
B
SERVER A1 à RING 1 : 172.20.110.1
SERVER A2 à RING 2 : 172.20.120.1
SERVER B1 à RING 1 : 172.20.110.2
SERVER B2 à RING 2 : 172.20.120.2
SW1
SW2
172.20.110.201
172.20.110.202
SW4
172.20.120.204
SW5
172.20.120.205
SW6
172.20.120.206
SW3
CRP
NOE3
NOE2
NOE 1 : 172.20.110.111
NOE 2 : 172.20.120.121
NOE1
CRP
NOE3
NOE2
NOE 1 : 172.20.110.110
NOE 2 : 172.20.120.120
NOE1
172.20.110.203
In this section, we will describe the configuration of the communication between the
SCADA system and the Quantum PAC units. The SCADA system and the PAC units
communicate using an OPC server (OFS – OPC Factory Server).
43
4-Configuration
OFS
OFSOPC
Quantum
Vijeo Citect
SCADA SERVER
The below diagram describes all the elements which must be configured within Vijeo
Citect – for more details, see the Annexes section.
The main scope of this document being the Quantum hot standby, the detailed
SCADA configuration procedure is available in the appendix chapter.
44
4-Configuration
4.2. Switches configuration
The aim of this section is to describe the configuration of the switches of the control
network and field network switches.
4.2.1. Control network switches
The control network uses the protocol Media Redundancy Protocol (MRP). The MRP
principle states that one Ethernet switch of the ring must be defined as the
redundancy manager, and is such termed the Media Redundancy Manager. The
redundancy manager behaves as an on/off switch, which opens the network loop or
closes it depending on the state of the other devices on the network.
Control Ethernet Network
To SCADA
MRP Ring
manager
To SCADA
SW1
SW2
172.20.110.201
172.20.110.202
SW5
SW4
172.20.120.205
172.20.120.204
SW6
172.20.120.206
SW3
PRIMARY QUANTUM
CRP
NOE3
NOE2
NOE 1 : 172.20.110.111
NOE 2 : 172.20.120.121
NOE1
CRP
NOE3
NOE2
NOE 1 : 172.20.110.110
NOE 2 : 172.20.120.120
NOE1
172.20.110.203
STANDBY QUANTUM
The configuration of an Ethernet switch is completed via its embedded web server
(ConneXium TCESSM Web Server) and accessed by typing its IP address into the
address bar of an Internet browser. The IP address of the Ethernet switch has been
set using the “Ethernet Switch” software provided with the respective Ethernet switch.
We set the mask to 255.255.0.0 so that all our devices are accessible from any point
on the network (this makes the configuration easier)
The following login and password are required to access the web server:
• Login: admin
• Password: private
45
4-Configuration
Once logged in, the system page opens, presenting the visual aspect of the Ethernet
switch and its name. The different configuration tools of the server are accessible via
the menu on the left.
The configuration of the control network switches is detailed in the following
screenshots.
Note: before configuring a switch, it is better to reset it to its factory settings to avoid
remnants of older configurations: go to the Load / Save menu and choose Delete
Current Configuration.
46
4-Configuration
In our configuration, switches SW1 and SW4 are set as the Redundancy Managers.
From the Redundancy menu, click Ring Redundancy to access the MRP
configuration of the Ethernet switch.
Note: To avoid loops during the Ethernet switch configuration do not connect the
redundant path until you have completed the Ring Redundancy configuration.
It is important to unplug the cable from
port 2 and connect the computer on port 3.
In addition, set the dipswitches on the
Ethernet switch front panel, labeled “RM”
and “Stand by”, to the ON (rightmost)
position to enable software ring
configuration via a Web Interface.
47
4-Configuration
The following table describes each step of the Ethernet switch SW2 configuration:
Step
Action
Select the type of redundancy protocol - HIPER-Ring / MRP
Select the MRP radio button.
1
Selection of Ring Ports
Enter port numbers corresponding to the ports assigned to the ring
connection, namely 1 and 2, respectively in Ring Port 1 and Ring Port 2
areas.
2
Note: When the ring is operational the port status is displayed. At this
stage, no information is presented. Port status values include the
following:
forwarding: this port is switched on and has a link
blocked: this port is blocked and has a link
disabled: this port is switched off
not connected: this port has no link
Enable Redundancy Manager
Select the On button in the Redundancy Manager area.
3
48
4-Configuration
Step
Action
Validate Advanced Mode for fast switching time
Click the Advanced Mode check box in the Configuration Redundancy
Manager area.
4
Switch on operation
Validate the On button in the Operation area to allow the validation of the
modifications.
5
Validate 200 ms Ring Recovery
The Ring Recovery group box presents two selections:
Standard Recovery (500 ms) or Accelerated Recovery (200 ms) for the
Ethernet switch activated as the Redundancy Manager.
6
Select the accelerated recovery 200 ms button.
Disable VLAN Assignments on ring ports
Assuming no VLAN is required, set VLAN ID to 0 in the VLAN area.
7
Validation of the configuration
8
Click the Set button to apply the configuration changes.
49
4-Configuration
Step
Action
Saving the configuration
The modified configuration is only present in the Ethernet switch 2
dynamic memory.
To preserve these changes in the event of a power outage, the
configuration must be saved.
Click the menu Basic Settings, then the Load/Save entry.
9
Select the to Device button in the Save area.
Then click the Save button.
The configuration of Ethernet switch 2 is now complete.
To configure the other switches, the procedure is the same as above except that the
Redundancy Manager parameter must be set to Off and the Advanced Mode must
NOT be selected. A summary of the configuration is displayed on the screenshot
below:
On the fiber switches (SW2 and SW6), the ports 1 and 2 are dedicated to the fiber
network. It important to make sure the MRP ring ports are configured to ports 3 and 4
as below:
50
4-Configuration
4.2.2. Field network switches
The field network switches (SW7, SW8, SW11 and SW12) use the Rapid Spanning
Tree Protocol (RSTP). Unlike MRP, RSTP does not have a fixed ring manager; the
manager (named root bridge) is defined with a priority system. The messages are
then sent using the better path (with a costs system).
In our system, the primary Quantum is the default root bridge, and the secondary
Quantum is the backup root bridge. The other priorities and the path costs are set
automatically with pre-configuration profile files when using the extended Ethernet
and optical fiber switches. There is a certain number of these files depending on the
usage of the Ethernet switch; they are detailed in the Quantum Ethernet system
planning guide.
51
4-Configuration
Devices Ethernet Network
RSTP
bridge
CRP
NOE3
NOE 3 : 172.20.130.131
NOE2
Root (standby)
CRP : 172.20.130.1
NOE1
CRP
NOE3
NOE2
NOE 3 : 172.20.130.130
NOE1
Root (primary)
CRP : 172.20.130.2
DRS predifined
configuration
C15
PRIMARY QUANTUM
SW11
STB
172.20.130.54
SW8
C15
172.20.130.208
SW12
C5
C5
STB
172.20.130.64
172.20.130.212
172.20.130.211
ATV71
172.20.130.50
STB
172.20.130.55
STANDBY QUANTUM
SW7 C15
172.20.130.207
ATV71
172.20.130.60
SW9 root
CRA : 172.20.130.6
SW10
CRA
CRA
CRA : 172.20.130.3
172.20.130.209
STB
172.20.130.65
DROP 4
DROP 1
root
172.20.130.210
CRA : 172.20.130.7
CRA
CRA : 172.20.130.4
STB
172.20.130.51
STB
172.20.130.58
CRA : 172.20.130.8
CRA
CRA : 172.20.130.5
CRA
TESYS T
172.20.130.62
DROP 6
DROP 3
TESYS T
172.20.130.52
STB
172.20.130.67
STB
172.20.130.61
TESYS U
STB
172.20.130.57
STB
172.20.130.66
DROP 5
DROP 2
CRA
STB
172.20.130.56
TESYS U
STB
172.20.130.68
52
4-Configuration
Main field network loop
The switches SW7 and SW8 have to manage an optical fiber as part of the main loop,
but no extra loop. They have to be configured with the predefined configuration C15
Copper/Fiber Connection for a Long-haul Hot Standby Link Obtaining and Installing
Predefined Configuration Files as described below:
Step
Action
Connect to the Ethernet switch from a web browser.
Login: admin
Password: private
1
Note: before configuring a switch, it is better to reset it to its factory settings to
avoid remnants of older configurations: go to the Load / Save menu and choose
Delete Current Configuration.
53
4-Configuration
Step
Action
Set the switch name:
2
On the menu on the left, go to Load/Save. In the Load section on the page,
select the via PC item, then click the Restore button.
3
Select the profile named C15_CRPLinkHotStandbyLDV1.01.cfg and click Open.
4
Then click the Set button. This loads the standard configuration with all the
RSTP parameters needed for this Ethernet switch.
54
4-Configuration
Step
Action
The load can be checked on the System page (accessible from the menu on the
left). You can also see on the Dual RSTP page that the RSTP has been
activated and configured:
5
The switches SW11 and SW12 have to manage an optical fiber as part of the main
loop, and an extra loop each for the drops. The switches SW11 and SW12 have to be
configured with the standard configuration C5 Copper/Fiber Main Ring Connections
and RIO Sub-ring with DIO Clouds. Use the same procedure as SW7, but load this
profile instead at step 3:
C5_RIOMainRingFxTx_RIOSubRingTx_DIOCloudsTxV1.01.cfg
The resulting RSTP configuration should look like the following screenshot:
55
4-Configuration
DIO clouds networks loops
The DIO clouds Ethernet switches (SW9 and SW10) are needed to manage a part of
the DIO clouds devices with the RSTP protocol. Each of these switches manages a
loop of STB Advantys modules. This loop is managed with RSTP.
The link between the main field network loop and the DIO clouds loops is not a RSTP
link. Therefore, from the RSTP point of view, the DIO clouds are independent from
the main field network loop, which is why these switches are all configured as root.
The following table describes each step in configuring the switches SW9 and SW10:
Step
Action
Deactivate the MRP
From the Redundancy menu, click Ring Redundancy to access the MRP configuration of the
Ethernet switch. Remember to check that the MRP is not activated.
1
56
4-Configuration
Step
Action
From the Redundancy menu, click Rapid Spanning Tree, and Global to access the RSTP
configuration of the Ethernet switch
2
RSTP Activation:
Validate the On button in the Operation area to activate the RSTP protocol
3
MRP Compatibility deactivation
Validate the Off button in the MRP Compatibility area to completely deactivate the MRP
4
57
4-Configuration
Step
Action
RSTP Configuration
Set the Priority parameter to 0 (Root)
5
6
Validation of the configuration
Click the Set button to apply the configuration changes
In the menu on the left, in the Rapid Spanning Tree section, click on Port to access the
selection of ports to activate in RSTP. In the column “STP State Enable”, select the ports 1
and 2, which are the ports on which the STB loop is connected
7
8
Validation of the configuration
Click the Set button to apply the configuration changes
58
4-Configuration
Step
9
Action
Saving the configuration
Click the Basic Settings menu, then the Load/Save entry
Select to Device radio button in the Save area
Click the Save button
The configuration of Ethernet switch is now complete
4.2.3. Switches configuration summary
The following table summarizes the configuration of all switches:
Switch
reference
SW1 TCSESM083F23F0
SW2 TCSESM083F2CU0
SW3 TCSESM083F23F0
SW4 TCSESM083F23F0
SW5 TCSESM083F23F0
SW6 TCSESM083F2CU0
SW7 TCSESM063F2CS1
SW8 TCSESM063F2CS1
SW9 TCSESM083F23F0
SW10 TCSESM083F23F0
SW11 TCSESM063F2CS1
SW12 TCSESM063F2CS1
network
category
SCADA
SCADA
SCADA
SCADA
SCADA
SCADA
Field
Field
Field
Field
Field
Field
sub-network
Control ring 1
Control ring 1
Control ring 1
Control ring 2
Control ring 2
Control ring 2
Main loop
Main loop
DIO cloud 1
DIO cloud 2
Drops loop 1
Drops loop 2
IP address
172.20.110.201
172.20.110.202
172.20.110.203
172.20.120.204
172.20.120.205
172.20.120.206
172.20.130.207
172.20.130.208
172.20.130.209
172.20.130.210
172.20.130.211
172.20.130.212
fiber
X
X
X
X
X
X
MRP
RSTP
manager ring ports profile primary ring secondary ring
X
1 and 2
3 and 4
1 and 2
X
1 and 2
1 and 2
3 and 4
C15 ports 1 and 3
C15 ports 1 and 3
ports 1 and 2
ports 1 and 2
C5
ports 1 and 3
ports 5 and 6
C5
ports 1 and 3
ports 5 and 6
4.3. PAC configuration
4.3.1. Hardware configuration
The hardware setup used in this TVDA is mainly composed of two identical PACs for
HotStandby capabilities. Each PAC is built with the following elements:
•
One power module
•
One CPU module (140 CPU 672 61)
•
Three Ethernet modules (140 NOE 771 11)
•
One controller for remote I/Os (140 CRP 312 00)
59
4-Configuration
Primary Quantum
Secondary Quantum
The six drops (two remote sub-rings composed of three drops each) are composed of
the following elements:
•
One power module
•
One Ethernet slave module (140 CRA 312 00)
The other free slots can be filled with a large range of digital and analog I/O elements.
Following is the configuration of the six drops:
Drop 1
Drop 2
Drop 3
Drop 4
Drop 5
Drop 6
60
4-Configuration
The CRA 312 00 communication modules all need an address that can be configured
physically as described in the figure below:
The addresses configured with the rotary
switches should all be different on the network
(01 to 06 in our case).
4.3.2. CPU configuration
In Unity Pro, from the Configuration tab, we define the memory address range used
for the application (State RAM).
For a Hot Standby application it is recommended to check the Online modification in
RUN option. This makes it possible to add or delete discrete or analog modules and
modify parameters while the CPU remains online.
The following screenshot summarizes the configuration:
61
4-Configuration
4.3.3. Hot Standby configuration
In the Hot Standby tab of the CPU configuration we can set the Hot Standby runtime
parameters.
62
4-Configuration
CPU Run Mode
In the Run Mode area, we can define which PAC will be the primary PAC at system
power up. If both PACs are declared ‘Online’, the PAC with the lowest MAC address
will be the primary PAC.
•
Controller A, select Online
•
Controller B, select Online
Logic Mismatch
This parameter defines the PAC mode if a program mismatch is detected between
the primary and the standby PACs. Select Offline.
Keypad
The Invalidate Keypad parameter allows inhibiting keypad commands to be sent from
the Hot Standby menu. Do not select this option.
Swap Address
This parameter allows CPU memory swapping in case of a switchover.
63
4-Configuration
Non-transfer area
This area is defined by the user and words located in this area will not be transferred
to the Standby PAC. This area is used for specific operations performed by the
primary PAC and must not impact the standby PAC. For our application, we set a
2000-word zone from %MW100.
Behavior in Run Offline mode
When a Quantum cannot connect to the other Quantum, or when the other Quantum
is not ready, then it is in Run Offline mode. In this case, this Quantum is in charge of
driving the whole system, so we want the CPU to execute all code sections.
4.3.4. CRP configuration
The CRP is the module that manages the drops. Open the CRP configuration window
and enter the parameters below in the IPConfig tab:
64
4-Configuration
The IP addresses A and B are the primary and standby IP addresses (in our case
172.20.130.1 and 172.20.130.2 respectively). The subnet mask must be set to
255.255.0.0 in our application.
In the section below, the IP addresses of the drops must be set. In our application,
these addresses are 172.20.130.3 to 172.20.130.8. The device names are generated
automatically.
The RSTP tab must also be configured because our Quantum PACs are RSTP roots
on our field network. Therefore, the bridge priority must be set to Root(0).
65
4-Configuration
4.3.5. Quantum Ethernet modules (NOE)
The Quantum Ethernet modules (NOE) are the modules that manage the Ethernet of
the Quantum. In our architecture, we have three different networks, which is why
each Quantum has three NOEs – one for each network. In our case, we have:
•
NOE1: Ring_1 (Control network ring 1 for SCADA)
•
NOE2: Ring_2 (Control network 2 for SCADA)
•
NOE3: Ethernet_Devices (field network) ; this NOE is connected to the CRP
Control ring 1
Open the IP Configuration tab and enter for following information:
66
4-Configuration
IP Address: 172.20.110.110
Subnetwork mask: 255.255.0.0
67
4-Configuration
Control ring 2
Open the IP Configuration tab and enter for following information:
IP Address: 172.20.120.120
Subnetwork mask: 255.255.0.0
Field network
Open the IP Configuration tab and enter for following information:
IP Address: 172.20.130.130
Subnetwork mask: 255.255.0.0
68
4-Configuration
For this network, the module utilities section must be changed so the IO Scanning
element must be set to YES.
Then open the IO Scanning tab. Following is a list of the DIO clouds devices IP
addresses:
69
4-Configuration
Ethernet switch SW9:
STB
172.20.130.54
ATV71
172.20.130.50
STB
172.20.130.55
•
ATV71: 172.20.130.50
•
STB: 172.20.130.51
•
TESYS T: 172.20.130.52
SW9
172.20.130.209
STB
172.20.130.56
STB
172.20.130.51
TESYS U
STB
172.20.130.57
TESYS T
172.20.130.52
STB
172.20.130.58
o
STB 1: 172.20.130.54
o
STB 2: 172.20.130.55
o
STB 3: 172.20.130.56
o
STB 4: 172.20.130.57
o
STB 5: 172.20.130.58
Ethernet switch SW10:
STB
172.20.130.64
ATV71
172.20.130.60
STB
172.20.130.65
SW10
172.20.130.210
STB
172.20.130.66
STB
172.20.130.67
STB
172.20.130.61
TESYS T
172.20.130.62
TESYS U
STB
172.20.130.68
•
ATV71: 172.20.130.60
•
STB: 172.20.130.61
•
TESYS T: 172.20.130.62
o
STB 1: 172.20.130.64
o
STB 2: 172.20.130.65
o
STB 3: 172.20.130.66
o
STB 4: 172.20.130.67
o
STB 5: 172.20.130.68
The configuration window is displayed below:
70
4-Configuration
Note: New TeSys T modules with double attachment must have the Unit ID
configured to 0.
4.3.6. CRA configuration
The CRA is the counterpart of the CRP on the drop side. In other words, it is the
module that receives the commands from the CRP and sends them to the I/O
modules of the drop.
Open the configuration window of the drop 1:
71
4-Configuration
Following are the parameters that should be configured:
In the address information section the device name, IP address and network mask
are grayed and cannot be set as they were already configured in the previous section.
The Tens and Ones fields should be identical as to what has been physically
configured on the CRA (see section 4.3.1.).
The Hold up time parameter should be left at its default value (1 second)
In a Hot Standby system it is recommended NOT to customize the RPI value. In this
case, the RPI value is one quarter of the watchdog time for a cyclic MAST task.
The RTSP of the CRA must be configured to Participant as displayed below:
72
4-Configuration
Repeat these operations for each drop but change the address information according
to their physical configuration.
4.3.7. STB network configuration
The DIO clouds network loops use RSTP, so the STB modules have to be configured
accordingly using Advantys configuration software.
For each STB, the IP address and subnet mask has to be configured in the Ethernet
parameters tab as shown below:
73
4-Configuration
The IP address is different for each STB:
Local DIO cloud:
•
STB 1: 172.20.130.54
•
STB 2: 172.20.130.55
•
STB 3: 172.20.130.56
•
STB 4: 172.20.130.57
•
STB 5: 172.20.130.58
Distant DIO cloud:
•
STB 1: 172.20.130.64
•
STB 2: 172.20.130.65
•
STB 3: 172.20.130.66
•
STB 4: 172.20.130.67
•
STB 5: 172.20.130.68
For each STB, the RSTP must be enabled and the bridge priority must be set to the
value 61 440 as shown below:
74
4-Configuration
75
4-Configuration
76
5-Implementation
5. Implementation
This chapter describes the steps in defining a program for a Hot Standby system
using Unity Pro. We will detail the monitoring DFB implementation presented in the
Design chapter. The completion of the I/O Device implementation with Vijeo Citect will
also be described in this chapter.
5.1. Monitoring Elements in the Primary Section
5.1.1. Ethernet Control ring monitoring
The Ethernet control ring is managed by a 140 NOE 771 11 Ethernet communication
module. The DFB NOE_Monitor uses the variables structure NOE_Monit to monitor
the Ethernet link.
The DFB and the variables structure are both presented in the Design chapter.
5.1.2. NOE_Monitor DFB implementation
PRIM_NOE_RING_1
NOE_Monit or
PRIM_NOE_RING1.MSTR_active
PRIM_NOE_RING1.MSTR_done
PRIM_NOE_RING1.MSTR_error
PRIM_NOE_RING1.MSTR_RateEt
PRIM_NOE_RING1.MSTR_ErrorCount
MSTR_ACTIVE
MSTR_DONE
MSTR_ERROR
RateEt
Error_Count
MSTR_ACTIVE
MSTR_DONE
MSTR_ERROR
RateEt
Error_Count
PRIM_NOE_RING1.MSTR_active
PRIM_NOE_RING1.MSTR_done
PRIM_NOE_RING1.MSTR_error
PRIM_NOE_RING1.MSTR_RateEt
PRIM_NOE_RING1.MSTR_ErrorCount
PRIM_NOE_RING1.MSTR_Control
MSTR_Control
MSTR_Control
MSTR_DataBuf
PRIM_NOE_RING1.MSTR_Control
PRIM_NOE_RING1.MSTR_Databuf
4
2
2
Pulse
Slot
MonitoringRate
Retries
Pulse
Data_TCP
LED_APPL
LED_LINK
LED_RUN
NOE_Failure
CFG_PORT
ETH_100M
OPTICFIB
FULL_DUP
DUP_ADD
FAULT
EQUP_TYP
IP_AD_1
IP_AD_2
IP_AD_3
IP_AD_4
MAC_ADD_1
MAC_ADD_2
MAC_ADD_3
MAC_ADD_4
MAC_ADD_5
MAC_ADD_6
PRIM_NOE_RING1.MSTR_data
PRIM_NOE_RING1.Led_Appl
PRIM_NOE_RING1.Led_Link
PRIM_NOE_RING1.Led_Run
PRIM_NOE_RING1.Failure
PRIM_NOE_RING1.Led_Cfg_Port
PRIM_NOE_RING1.Led_Eth_100M
PRIM_NOE_RING1.Led_OpticFib
PRIM_NOE_RING1.Led_Full_Dup
PRIM_NOE_RING1.DUP_ADD
PRIM_NOE_RING1.Fault
PRIM_NOE_RING1.EQUIP_TYPE
PRIM_NOE_RING1.IP_AD_1
PRIM_NOE_RING1.IP_AD_2
PRIM_NOE_RING1.IP_AD_3
PRIM_NOE_RING1.IP_AD_4
PRIM_NOE_RING1.MAC_AD_1
PRIM_NOE_RING1.MAC_AD_2
PRIM_NOE_RING1.MAC_AD_3
PRIM_NOE_RING1.MAC_AD_4
PRIM_NOE_RING1.MAC_AD_5
PRIM_NOE_RING1.MAC_AD_6
77
5-Implementation
Step
1
2
Action
Instantiate the DFB NOE_Monitor under the name PRIM_NOE_RING_1
Instantiate the variables structure NOE_Monit under the name
PRIM_NOE_CTRL
3
Connect the variables of the structure on the DFB pins
4
For the pin named Slot, enter the value 4. This corresponds to the NOE
module slot number in the hardware configuration
5
On the Pulse pin connect the variable pulse computed at the beginning
of the primary section. This pulse indicates each cycle beginning.
For the pin named Monitoring Rate, enter the value 2. This means that
the local statistics are extracted from the MBP_MSTR function every two
cycles
6
For the pin named Retries, enter the value 2. This corresponds to the
maximum number of unsuccessful attempts at extracting the local
statistics from the MBP_MSTR that will be tolerated before issuing an
exception response
5.1.3. Devices Ethernet Ring Monitoring
The devices Ethernet ring is also managed by a 140 NOE 771 11 Ethernet
communication module. Just as with the Ethernet control ring, the DFB NOE_Monitor
uses the variables structure NOE_Monit to monitor the Ethernet link.
78
5-Implementation
PRIM_NOE_DEV
NOE_Monit or
PRIM_NOE_DEVICES.MSTR_active
PRIM_NOE_DEVICES.MSTR_done
PRIM_NOE_DEVICES.MSTR_error
PRIM_NOE_DEVICES.MSTR_RateEt
PRIM_NOE_DEVICES.MSTR_ErrorCount
MSTR_ACTIVE
MSTR_DONE
MSTR_ERROR
RateEt
Error_Count
MSTR_ACTIVE
MSTR_DONE
MSTR_ERROR
RateEt
Error_Count
PRIM_NOE_DEVICES.MSTR_active
PRIM_NOE_DEVICES.MSTR_done
PRIM_NOE_DEVICES.MSTR_error
PRIM_NOE_DEVICES.MSTR_RateEt
PRIM_NOE_DEVICES.MSTR_ErrorCount
PRIM_NOE_DEVICES.MSTR_Control
MSTR_Control
MSTR_Control
MSTR_DataBuf
PRIM_NOE_DEVICES.MSTR_Control
PRIM_NOE_DEVICES.MSTR_Databuf
6
2
2
Pulse
Slot
MonitoringRate
Retries
Pulse
Data_TCP
LED_APPL
LED_LINK
LED_RUN
NOE_Failure
CFG_PORT
ETH_100M
OPTICFIB
FULL_DUP
DUP_ADD
FAULT
EQUP_TYP
IP_AD_1
IP_AD_2
IP_AD_3
IP_AD_4
MAC_ADD_1
MAC_ADD_2
MAC_ADD_3
MAC_ADD_4
MAC_ADD_5
MAC_ADD_6
Step
1
2
PRIM_NOE_DEVICES.MSTR_data
PRIM_NOE_DEVICES.Led_Appl
PRIM_NOE_DEVICES.Led_Link
PRIM_NOE_DEVICES.Led_Run
PRIM_NOE_DEVICES.Failure
PRIM_NOE_DEVICES.Led_Cfg_Port
PRIM_NOE_DEVICES.Led_Eth_100M
PRIM_NOE_DEVICES.Led_OpticFib
PRIM_NOE_DEVICES.Led_Full_Dup
PRIM_NOE_DEVICES.DUP_ADD
PRIM_NOE_DEVICES.Fault
PRIM_NOE_DEVICES.EQUIP_TYPE
PRIM_NOE_DEVICES.IP_AD_1
PRIM_NOE_DEVICES.IP_AD_2
PRIM_NOE_DEVICES.IP_AD_3
PRIM_NOE_DEVICES.IP_AD_4
PRIM_NOE_DEVICES.MAC_AD_1
PRIM_NOE_DEVICES.MAC_AD_2
PRIM_NOE_DEVICES.MAC_AD_3
PRIM_NOE_DEVICES.MAC_AD_4
PRIM_NOE_DEVICES.MAC_AD_5
PRIM_NOE_DEVICES.MAC_AD_6
Action
Instantiate the DFB NOE_Monitor under the name PRIM_NOE_DEV
Instantiate the variables structure NOE_Monit under the name
PRIM_NOE_DEVICES located in the non-transfer area
3
Connect the variables from the structure on the DFB pins
4
For the pin named Slot, enter the value 6
5
For the pin named Monitoring Rate, enter the value 2
6
For the pin named Retries, enter the value 2
To manage the Hot Standby system, the FAULT output of this DFB is used as an
input in the Fault synthesis. This operation is described in section 5.1.5.
79
5-Implementation
5.1.4. Monitoring Rate Pulse
In order to control the NOE_Monitor block monitoring rate (execution of the
MBP_MSTR function), a pulse signal is implemented. This pulse signal is a trigger at
the beginning of each program cycle.The monitoring rate varies according to the cycle
length of the application.
HSBY_ST
HSBY
THIS_OFF
THIS_PRY
THIS_SBY
REMT_OFF
REMT_PRY
REMT_SBY
LOGIC_OK
THIS_ISA
THIS_ISB
HSBY_CONF_OK
THIS_OFFLINE
THIS_PRIMARY
THIS_STANDBY
REMOTE_OFFLINE
REMOTE_PRIMARY
REMOTE_STANDBY
INC
CycleNb
EN
INOUT
ENO
INOUT
CycleNb
CycleNb
1
EN
IN1
IN2
GT
ENO
OUT
0
R_TRIG
EN
ENO
CLK
Q
Pulse
MOVE
EN
ENO
CLK
Q
CycleNb
5.1.5. Fault Synthesis
The fault synthesis comprises two parts. Firstly, a synthesis of the NOE module faults
is performed. Then, a faults synthesis is performed using a mask that makes it
possible to inhibit specific faults. To implement this synthesis, we use the DFBs
presented in the Design chapter: SYNTH_OR_NOE and SYNTH_FAULT.
The aim from the NOE side is to cause the following behavior:

If one of the two Control networks is lost, then the system will switch over to
the other control network

If both control networks are lost, then the system will switch to the other
Quantum

If the DIO network is lost, then the system will switch to the other Quantum
80
5-Implementation
PRIM_NOE_SCADA_FAULT_SYNTH
SYNTH_AND_NOE
PRIM_NOE_RING1_Fault
PRIM_NOE_RING2_Fault
False
False
False
False
FAULT_NOE
FLT_NOE_1
FLT_NOE_2
FLT_NOE_3
FLT_NOE_4
FLT_NOE_5
FLT_NOE_6
PRIM_NOE_FAULT_SYNTH
SYNTH_OR_NOE
False
PRIM_NOE_DEVICES_Fault
False
False
False
FLT_NOE_1
FLT_NOE_2
FLT_NOE_3
FLT_NOE_4
FLT_NOE_5
FLT_NOE_6
FAULT_NOE
PRIM_SYNTH_FAULT
SYNTH_FAULT
False
False
2# 0000_1100_0111_1111
Faulty_NOE
Faulty_PTQ
Faulty_SCADA
Fault_Mask
Fault_Synth
Fault
PRIM_SYNTH_FLT_PLC
PRIM_FAULT_PLC
Part 1: NOE Synthesis
Step
1
2
3
4
Action
Instantiate the DFB SYNTH_AND_NOE under the name
PRIM_NOE_SCADA_FAULT_SYNTH
Connect the variable PRIM_NOE_CTRL_FAULT previously computed by
the PRIM_NOE_RING1 DFB on the pin FLT_NOE_1
Connect the variable PRIM_NOE_CTRL_FAULT previously computed by
the PRIM_NOE_RING1 DFB on the pin FLT_NOE_2
Connect a False variable (unlocated) on all the other pins
Part 2: NOE Synthesis
Step
1
2
3
Action
Instantiate the DFB SYNTH_OR_NOE under the name
PRIM_NOE_FAULT_SYNTH
On the pin FLT_NOE_1, connect the output of the block described in part
1 above
Connect the variable PRIM_NOE_DEVICES_FAULT previously
computed by the PRIM_NOE_DEV DFB on the pin FLT_NOE_3
81
5-Implementation
Step
4
Action
Connect a False variable (unlocated) on all the other pins
Part 3: FAULT Synthesis
Step
1
2
3
4
Action
Instantiate the DFB SYNTH_FAULT under the name
PRIM_SYNTH_FAULT
Link the input pin Faulty_NOE to the output pin Fault_NOE of the
PRIM_NOE_FAULT_SYNTH DFB
On the Faulty_PTQ pin, connect a False variable. Our application does
not include blocks dedicated to PTQ
On the Faulty_Scada pin, connect a False variable. Our application does
not include blocks dedicated to SCADA system monitoring
We now need to define which event will initiate a switchover. The table
below is used to ‘compose’ the mask and define the monitoring filter to
apply as an input of the DFB. The mask value to be set on the
Fault_Mask pin is 2#0000011000111111
5
Bit
Elements
Fault Mask Definition
Bit 0
Battery fault
1
Bit 1
CPU fault
1
Bit 2
General I/O rack fault
1
Bit 3
Fault on slot 3
1
Bit 4
Fault on slot 4
1
Bit 5
Fault on slot 5
1
Bit 6
Fault on slot 6
1
Bit 7
Fault on slot 7
0
Bit 8
Fault on slot 8
0
Bit 9
Fault on slot 9
0
Bit 10
Fault on slot 10
1
Bit 11
Ethernet Adapter(s) NOE Fault
1
Bit 12
Profibus DP Adapter(s) Fault
0
Bit 13
SCADA Fault
0
Bit 14
-
0
Bit 15
-
0
82
5-Implementation
Step
Action
On the Fault_Synth pin, connect the variable RIM_SYNTH_FLT_PLC
6
located in the non-transfer area. This word represents the Primary
configuration Fault synthesis after the Fault_Mask filter. It will be used in
the determination of the switchover.
On the Fault pin, connect the variable PRIM_FAULT_PLC located in the
7
non-transfer area. This Boolean information indicates a fault detection
after the Fault_Mask filter.
5.2. Monitoring Elements in the Standby Section
In this section, which is the only one executed by the Standby PAC, we find the same
elements as in the Primary Section.
5.2.1. Controller Ethernet Ring Monitoring
DFB NOE_Monitor implementation:
STBY_NOE_RING_1
%SW61.0
STBY_NOE_RING1.MSTR_active
STBY_NOE_RING1.MSTR_done
STBY_NOE_RING1.MSTR_error
STBY_NOE_RING1.MSTR_RateEt
STBY_NOE_RING1.MSTR_ErrorCount
STBY_NOE_RING1.MSTR_Control
4
2
2
Pulse
NOE_Monit or
EN
MSTR_ACTIVE
MSTR_ACTIVE
MSTR_DONE
MSTR_DONE
MSTR_ERROR
MSTR_ERROR
RateEt
RateEt
Error_Count
Error_Count
MSTR_Control
Slot
MonitoringRate
Retries
Pulse
MSTR_Control
MSTR_DataBuf
Data_TCP
LED_APPL
LED_LINK
LED_RUN
NOE_Failure
CFG_PORT
ETH_100M
OPTICFIB
FULL_DUP
DUP_ADD
FAULT
EQUP_TYP
IP_AD_1
IP_AD_2
IP_AD_3
IP_AD_4
MAC_ADD_1
MAC_ADD_2
MAC_ADD_3
MAC_ADD_4
MAC_ADD_5
MAC_ADD_6
Step
STBY_NOE_RING1.MSTR_active
STBY_NOE_RING1.MSTR_done
STBY_NOE_RING1.MSTR_error
STBY_NOE_RING1.MSTR_RateEt
STBY_NOE_RING1.MSTR_ErrorCount
STBY_NOE_RING1.MSTR_Control
STBY_NOE_RING1.MSTR_Databuf
STBY_NOE_RING1.MSTR_data
STBY_NOE_RING1.Led_Appl
STBY_NOE_RING1.Led_Link
STBY_NOE_RING1.Led_Run
STBY_NOE_RING1.Failure
STBY_NOE_RING1.Led_Cfg_Port
STBY_NOE_RING1.Led_Eth_100M
STBY_NOE_RING1.Led_OpticFib
STBY_NOE_RING1.Led_Full_Dup
STBY_NOE_RING1.DUP_ADD
STBY_NOE_RING1.Fault
STBY_NOE_RING1.EQUIP_TYPE
STBY_NOE_RING1.IP_AD_1
STBY_NOE_RING1.IP_AD_2
STBY_NOE_RING1.IP_AD_3
STBY_NOE_RING1.IP_AD_4
STBY_NOE_RING1.MAC_AD_1
STBY_NOE_RING1.MAC_AD_1
STBY_NOE_RING1.MAC_AD_2
STBY_NOE_RING1.MAC_AD_3
STBY_NOE_RING1.MAC_AD_4
STBY_NOE_RING1.MAC_AD_5
STBY_NOE_RING1.MAC_AD_6
Action
83
5-Implementation
Step
1
2
3
4
Action
Instantiate the DFB NOE_Monitor under the name
STDBY_NOE_RING_1
Instantiate a new structure NOE_Monit under the name
STBY_NOE_CTRL
Connect the structure variables on the pins of the DFB
On the pin Slot, enter the value 4 (position of the NOE module on the
rack)
5
On the pin Monitoring Rate, enter the value 2
6
On the pin Retries, enter the value 2
7
To verify that only the Standby PAC executes this block, we add a
condition on its execution.
Right click on the block and select Properties
8
9
Check the box Show EN/ENO. This enables a pin EN as input of the
DFB and a pin ENO as output.
On the pin EN, connect the bit 0 of the status register %SW61. This
indicates whether the PAC is Primary or Standby.
5.2.2. Devices Ethernet Ring Monitoring
DFB NOE_Monitor implementation:
84
5-Implementation
STBY_NOE_DEV
%SW61.0
STBY_NOE_DEVICES.MSTR_active
STBY_NOE_DEVICES.MSTR_done
STBY_NOE_DEVICES.MSTR_error
STBY_NOE_DEVICES.MSTR_RateEt
STBY_NOE_DEVICES.MSTR_ErrorCount
STBY_NOE_DEVICES.MSTR_Control
6
2
2
Pulse
NOE_Monit or
EN
MSTR_ACTIVE
MSTR_ACTIVE
MSTR_DONE
MSTR_DONE
MSTR_ERROR
MSTR_ERROR
RateEt
RateEt
Error_Count
Error_Count
MSTR_Control
Slot
MonitoringRate
Retries
Pulse
MSTR_Control
MSTR_DataBuf
STBY_NOE_DEVICES.MSTR_active
STBY_NOE_DEVICES.MSTR_done
STBY_NOE_DEVICES.MSTR_error
STBY_NOE_DEVICES.MSTR_RateEt
STBY_NOE_DEVICES.MSTR_ErrorCount
STBY_NOE_DEVICES.MSTR_Control
STBY_NOE_DEVICES.MSTR_Databuf
Data_TCP
LED_APPL
LED_LINK
LED_RUN
NOE_Failure
CFG_PORT
ETH_100M
OPTICFIB
FULL_DUP
DUP_ADD
FAULT
EQUP_TYP
STBY_NOE_DEVICES.MSTR_data
STBY_NOE_DEVICES.Led_Appl
STBY_NOE_DEVICES.Led_Link
STBY_NOE_DEVICES.Led_Run
STBY_NOE_DEVICES.Failure
STBY_NOE_DEVICES.Led_Cfg_Port
STBY_NOE_DEVICES.Led_Eth_100M
STBY_NOE_DEVICES.Led_OpticFib
STBY_NOE_DEVICES.Led_Full_Dup
STBY_NOE_DEVICES.DUP_ADD
STBY_NOE_DEVICES.Fault
STBY_NOE_DEVICES.EQUIP_TYPE
IP_AD_1
IP_AD_2
IP_AD_3
IP_AD_4
IP_AD_1
MAC_ADD_1
MAC_ADD_2
MAC_ADD_3
MAC_ADD_4
MAC_ADD_5
MAC_ADD_6
STBY_NOE_DEVICES.IP_AD_1
STBY_NOE_DEVICES.IP_AD_2
STBY_NOE_DEVICES.IP_AD_3
STBY_NOE_DEVICES.IP_AD_4
STBY_NOE_DEVICES.MAC_AD_1
STBY_NOE_DEVICES.MAC_AD_1
STBY_NOE_DEVICES.MAC_AD_2
STBY_NOE_DEVICES.MAC_AD_3
STBY_NOE_DEVICES.MAC_AD_4
STBY_NOE_DEVICES.MAC_AD_5
STBY_NOE_DEVICES.MAC_AD_6
85
5-Implementation
Step
Action
Instantiate the DFB NOE_Monitor under the name STDBY_NOE_DEV
1
Instantiate a new structure NOE_Monit under the name
2
STBY_NOE_DEVICES located in the non-transfer area
3
Connect the structure variables on the pins of the DFB
4
On the pin Slot, enter the value 6
5
On the pin Monitoring Rate, enter the value 2
6
On the pin Retries, enter the value 2
Repeat the preceding steps for the block execution and connect the bit 0
7
of the status register %SW61 on the pin EN
As with the Primary Section, the FAULT output of this DFB is used as an input in the
Fault synthesis
5.2.3. Fault Synthesis
In the standby section, the expected behavior is the same as in the primary section,
but the fact that the Quantum is standby must be taken into account. This is done
using the system word %SW61.
STBY_NOE_SCADA_FAULT_SYNTH
%SW61.0
STBY_NOE_RING1_Fault
STBY_NOE_RING2_Fault
False
False
False
False
SYNTH_AND_NOE
EN
FAULT_NOE
FLT_NOE_1
FLT_NOE_2
FLT_NOE_3
FLT_NOE_4
FLT_NOE_5
FLT_NOE_6
STBY_NOE_FAULT_SYNTH
%SW61.0
False
STBY_NOE_DEVICES_Fault
False
False
False
SYNTH_OR_NOE
EN
FAULT_NOE
FLT_NOE_1
FLT_NOE_2
FLT_NOE_3
FLT_NOE_4
FLT_NOE_5
FLT_NOE_6
STBY_SYNTH_FAULT
%SW61.0
False
False
2# 0000_1100_0111_1111
SYNTH_FAULT
EN
Faulty_NOE
Faulty_PTQ
Faulty_SCADA
Fault_Mask
Fault_Synth
Fault
STBY_SYNTH_FLT_PLC
STBY_FAULT_PLC
86
5-Implementation
Part 1: NOE SCADA Synthesis
Step
1
Action
Instantiate the DFB SYNTH_AND_NOE under the name
STDBY_NOE_SCADA_FAULT_SYNTH
On the pin FLT_NOE_1, connect the variable
2
STBY_NOE_CTRL_FAULT previously computed by the DFB
STBY_NOE_RING1
On the pin FLT_NOE_2, connect the variable
3
STBY_NOE_DEVICES_FAULT previously computed by the DFB
STBY_NOE_RING2
4
Connect a False variable (unlocated) on all the other pins
Part 2: NOE Synthesis
Step
1
2
Action
Instantiate the DFB SYNTH_OR_NOE under the name
STDBY_NOE_FAULT_SYNTH
On the pin FLT_NOE_1, connect the output of the block described in part
1 above
On the pin FLT_NOE_3, connect the variable
3
STBY_NOE_DEVICES_FAULT previously computed by the DFB
STBY_NOE_DEV
4
Connect a False variable (unlocated) on all the other pins
Part 3: FAULT Synthesis
Step
1
2
3
4
5
Action
Instantiate the DFB SYNTH_FAULT under the name
STDBY_SYNTH_FAULT
Link the input pin Faulty_NOE to the output pin Fault_NOE of the DFB
STDBY_NOE_FAULT_SYNTH
On the Faulty_PTQ pin, connect a False variable. Our application does
not include blocks dedicated to PTQ
On the Faulty_Scada pin, connect a False variable. Our application does
not include blocks dedicated to SCADA system monitoring
Set the Fault_Mask value with the same value as the Primary section,
which is 2#0000110001111111
87
5-Implementation
Step
Action
On the Fault_Synth output pin, connect the variable
STBY_SYNTH_FLT_PLC. This word represents the Standby
6
configuration Fault synthesis after the Fault_Mask filter. It will be used in
the determination of the switchover. Therefore, this variable is located on
the reverse register %SW62 that allows writing from Standby to Primary
On the Fault pin, connect the variable STBY_FAULT_PLC located in the
7
non-transfer area. This Boolean information indicates a fault detection
after the Fault_Mask filter
8
For each of these blocks, activate the execution option and connect the
bit 0 of the status register %SW61 on the pin EN.
5.3. Switchover Management
Once the monitoring DFB is implemented and the fault synthesis is computed in the
Primary and Standby sections, it is necessary to process the obtained data and to set
the switchover management rules.
To set the management rules we use the DFB Switch_Manag previously described in
the Design chapter. This DFB is instantiated in the Primary section.
DFB Switch_Manag implementation:
HSBY_SWITCH
SWITCH_MANAG
PRIM_SYNTH_FLT_PLC
STBY_SYNTH_FLT_PLC
Switch_Nb_Reset
Force_Switchover
Step
1
2
3
4
PRIM_DIAG
STBY_DIAG
SWITCH_NB_Reset
FORCE
SWITCH_NB
FORCE
Switch_Nb
Force_Switchover
Action
Instantiate the DFB SWITCH_MANAG under the name HSBY_SWITCH
Connect the variable PRIM_SYNTH_FLT_PLC (Primary PAC Fault
synthesis) on the pin PRIM_DIAG
Connect the variable STBY_SYNTH_FLT_PLC (Standby PAC Fault
synthesis) on the pin STBY_DIAG
Connect a variable Switch_Nb_Reset, located in the non-transfer area,
on the Switch_Nb_Reset pin
88
5-Implementation
Step
5
6
Action
Connect a variable Force_Switchover on the pin FORCE
On the output pin Switch_NB, connect a variable Switch_NB located in
the non-transfer area
The management of the Ethernet redundant links of the Quantum Hot Standby
system is now complete.
5.4. SCADA
5.4.1. OFS variables import
This section describes how to automatically link the variable tags from OFS to Vijeo
Citect using the variables import in Vijeo Citect.
In Citect Explorer, open the Tools menu and select Import tags.
The following window is opened:
In the Destination section, the field I/O Device should be set to IO_DEVICE_QUANT.
89
5-Implementation
In the Source section, set the database type to Unity SpeedLink to OFS. Then select
the external database using the Browse button. The following window opens:
Select OFS_QUANTUM_1 and click OK to validate and close the window.
The import variable tags window should now have the connection string field with the
value automatically set.
90
5-Implementation
Click the Import button to finalize the operation.
5.4.2. User interface
Using Vijeo Citect, we designed a user interface with the following information and
controls:

Status of the system registers (%SW60 and %SW61) of the primary Quantum

Display of the primary PAC (A or B)

Effective scan time of the primary PAC

Number of switchovers and the associated reset button

A button to force an applicative switchover
91
5-Implementation
When communication with the primary PAC is lost – which happens in case of
switchover, for example – the information is grayed as shown below:
92
5-Implementation
93
6-Validation
6. Validation
This chapter describes the various tests we performed on the different architectures
used for this document. The first section describes the functional tests, where the
general behavior of the system is compared to the expected behavior when given a
certain stimulus. The second section describes the performance tests, including
information on the time needed for different configurations of the system to perform
specific operations.
6.1. Functional tests
In this section we check that the system behaves correctly when exposed to some
specific changes in functionality and describes the functional tests. We grouped the
tests into three categories:
-
The Quantum failure tests check that the hot standby Quantum takes
control of the system when the primary Quantum fails
-
The Quantum cable break tests verify the behavior of the system when
Ethernet cables are cut, taking into account the specific libraries we
implemented
-
The SCADA perturbations tests show how the SCADA system reacts to
server stops or cable breaks
The results of all tests are summarized in section 6.1.4.
6.1.1. Quantum failure
In this section different conditions of failure of the Quantum are tested, including loss
of power supply, CPU, CRP and NOE failures.
Power supply down on primary Quantum
Action: shutdown primary Quantum power supply.
94
6-Validation
Expected behavior: hot-standby Quantum takes control of the system (switchover).
System-built-in function: yes. No additional code must be implemented for this
feature.
CPU failure on primary Quantum
Action: the CPU block of the primary Quantum is unplugged.
Expected behavior: hot-standby Quantum takes control of the system (switchover).
System-built-in function: yes. No additional code must be implemented for this
feature.
CRP failure on primary Quantum
Action: the CRP of the primary Quantum is unplugged.
95
6-Validation
Expected behavior: hot-standby Quantum takes control of the system (switchover).
System-built-in function: yes. No additional code must be implemented for this
feature.
NOE1 failure on primary Quantum
Action: the NOE1 (control ring 1) of the primary Quantum is unplugged.
Expected behavior: hot-standby Quantum takes control of the system (switchover).
System-built-in function: no. We implemented this behavior in our application, see
section 3.2.4.
NOE2 failure on primary Quantum
Action: the NOE2 (control ring 2) of the primary Quantum is unplugged.
96
6-Validation
Expected behavior: hot-standby Quantum takes control of the system (switchover).
System-built-in function: no. We implemented this behavior in our application, see
section 3.2.4.
NOE3 failure on primary Quantum
Action: the NOE3 (DIO clouds on field network) of the primary Quantum is
unplugged.
Expected behavior: hot-standby Quantum takes control of the system (switchover).
System-built-in function: no. We implemented this behavior in our application, see
section 3.2.4.
6.1.2. Quantum cable breakages
In this section, the tests concern different cases of Ethernet cable breakages on the
different networks – main loop of the field network, control rings (on the Quantum
side), and field network on the DIO side.
Cable break on field network (main loop)
Action: the Ethernet cable between the primary Quantum and the Ethernet switch
SW11 (field network main loop) is broken.
97
6-Validation
PRIMARY
SERVER
STANDBY
SERVER
VIJEO CITECT
CLIENT
SW1
SW2
SW5
SW4
SW6
CRP
NOE3
NOE2
NOE1
CRP
NOE3
NOE2
NOE1
SW3
STANDBY QUANTUM
PRIMARY QUANTUM
SW8
SW7
SW12
SW11
SW9
DROP 4
SW10
CRA
CRA
DROP 1
DROP 5
CRA
CRA
DROP 2
DROP 6
CRA
CRA
DROP 3
Expected behavior: the network switches and the Ethernet data uses an alternate
route.
System-built-in function: yes. No additional code must be implemented for this
feature.
Quantum cable break on control ring 1
Action: the cable between the primary Quantum and the Ethernet switch SW3
(control ring 1) is broken.
98
6-Validation
PRIMARY
SERVER
STANDBY
SERVER
VIJEO CITECT
CLIENT
SW1
SW2
SW5
SW4
SW6
CRP
NOE3
NOE2
NOE1
CRP
NOE3
NOE2
NOE1
SW3
STANDBY QUANTUM
PRIMARY QUANTUM
SW8
SW7
SW12
SW11
SW9
DROP 4
SW10
CRA
CRA
DROP 1
DROP 5
CRA
CRA
DROP 2
DROP 6
CRA
CRA
DROP 3
Expected behavior: The Quantum and the SCADA system communicate using the
control ring 2.
System-built-in function: no. We implemented this behavior in our application, see
section 3.2.4.
Quantum cable break on both control rings
Action: the cable between the primary Quantum and the Ethernet switch SW3
(control ring 1) is broken and the cable between the primary Quantum and the
Ethernet switch SW4 (control ring 2) is broken.
99
6-Validation
PRIMARY
SERVER
STANDBY
SERVER
VIJEO CITECT
CLIENT
SW1
SW2
SW5
SW4
SW6
CRP
NOE3
NOE2
NOE1
CRP
NOE3
NOE2
NOE1
SW3
STANDBY QUANTUM
PRIMARY QUANTUM
SW8
SW7
SW12
SW11
SW9
DROP 4
SW10
CRA
CRA
DROP 1
DROP 5
CRA
CRA
DROP 2
DROP 6
CRA
CRA
DROP 3
Expected behavior: hot-standby Quantum takes control of the system (switchover).
System-built-in function: no. We implemented this behavior in our application, see
section 3.2.4.
Cable break on field network (DIO clouds)
Action: the cable between the NOE3 and the CRP on the primary Quantum is
broken.
100
6-Validation
STANDBY
SERVER
VIJEO CITECT
CLIENT
SW1
CRP
NOE3
NOE2
NOE1
PRIMARY
SERVER
SW2
SW5
SW4
SW6
CRP
NOE3
NOE2
NOE1
CRP
NOE3
NOE2
NOE1
SW3
STANDBY QUANTUM
PRIMARY QUANTUM
SW8
SW7
SW12
SW11
SW9
DROP 4
SW10
CRA
CRA
DROP 1
DROP 5
CRA
CRA
DROP 2
DROP 6
CRA
CRA
DROP 3
Expected behavior: hot-standby Quantum takes control of the system (switchover).
System-built-in function: no. We implemented this behavior in our application, see
section 3.2.4.
101
6-Validation
6.1.3. SCADA perturbations
In this section the behavior of the SCADA system is studied when the following
perturbations occur: the I/O server (i.e. the service) is stopped, a different cable
breaks on the server side, and shutdown of the primary server (i.e. the physical
computer that runs the services). The priorities set to the different servers in the
SCADA configuration are mostly responsible for the behavior of the SCADA system.
I/O server A down
Action: I/O server A on the primary server is shutdown (service is stopped).
PRIMARY
SERVER
STANDBY
SERVER
VIJEO CITECT
CLIENT
SW1
SW2
SW5
SW4
SW6
CRP
NOE3
NOE2
NOE1
CRP
NOE3
NOE2
NOE1
SW3
STANDBY QUANTUM
PRIMARY QUANTUM
SW8
SW7
SW12
SW11
SW9
DROP 4
SW10
CRA
CRA
DROP 1
DROP 5
CRA
CRA
DROP 2
DROP 6
CRA
CRA
DROP 3
Expected behavior: I/O server B takes control of the SCADA process; alarms, trends
and reports servers, which usually run on server A.
System-built-in function: no. This behavior is configured in Vijeo Citect; for more
details, see section 4.1.
102
6-Validation
Port A1 cable break
Action: the cable between the primary server and Ethernet switch SW1 (control ring
1) is broken.
PRIMARY
SERVER
STANDBY
SERVER
VIJEO CITECT
CLIENT
SW1
SW2
SW5
SW4
SW6
CRP
NOE3
NOE2
NOE1
CRP
NOE3
NOE2
NOE1
SW3
STANDBY QUANTUM
PRIMARY QUANTUM
SW8
SW7
SW12
SW11
SW9
DROP 4
SW10
CRA
CRA
DROP 1
DROP 5
CRA
CRA
DROP 2
DROP 6
CRA
CRA
DROP 3
Expected behavior: server A switches to port A2 and uses control ring 2.
System-built-in function: no. This behavior is configured in Vijeo Citect; for more
details, see section 4.1.
103
6-Validation
Power supply down on server A
Action: server A is shutdown (the computer is stopped)
PRIMARY
SERVER
STANDBY
SERVER
VIJEO CITECT
CLIENT
SW1
SW2
SW5
SW4
SW6
CRP
NOE3
NOE2
NOE1
CRP
NOE3
NOE2
NOE1
SW3
STANDBY QUANTUM
PRIMARY QUANTUM
SW8
SW7
SW12
SW11
SW9
DROP 4
SW10
CRA
CRA
DROP 1
DROP 5
CRA
CRA
DROP 2
DROP 6
CRA
CRA
DROP 3
Expected behavior: server B takes control of the SCADA processes (I/O server and
ATR servers) using port B1 (control ring 1).
System-built-in function: no. This behavior is configured in Vijeo Citect; for more
details, see section 4.1.
104
6-Validation
Server A is down and port B1 cable break
Action: server A is shutdown (the computer is stopped) and the cable between the
standby server and Ethernet switch SW2 (control ring 1) is broken.
PRIMARY
SERVER
STANDBY
SERVER
VIJEO CITECT
CLIENT
SW1
SW2
SW5
SW4
SW6
CRP
NOE3
NOE2
NOE1
CRP
NOE3
NOE2
NOE1
SW3
STANDBY QUANTUM
PRIMARY QUANTUM
SW8
SW7
SW12
SW11
SW9
DROP 4
SW10
CRA
CRA
DROP 1
DROP 5
CRA
CRA
DROP 2
DROP 6
CRA
CRA
DROP 3
Expected behavior: server B takes control of all SCADA processes (I/O server and
ATR servers) using port B2 (control ring 2).
System-built-in function: no. This behavior is configured in Vijeo Citect; for more
details, see section 4.1.
105
6-Validation
6.1.4. Functional tests results
The table below summarizes the results of all the functional tests:
SCADA perturbations
Quantum cable breaks
Quantum switchover
cat.
Test description
Expected result
Actual result
Test pass
Power supply down on
primary Quantum
Quantum
switchover
Quantum
switchover
OK
CPU failure on primary
Quantum
Quantum
switchover
Quantum
switchover
OK
CRP unplugged on primary
Quantum
Quantum
switchover
Quantum
switchover
OK
NOE1 unplugged on
primary Quantum
Quantum
switchover
Quantum
switchover
OK
NOE2 unplugged on
primary Quantum
Quantum
switchover
Quantum
switchover
OK
NOE3 unplugged
Quantum
switchover
Quantum
switchover
OK
Quantum cable break on
field network (main loop)
network
reconfiguration
network
reconfiguration
OK
Quantum cable break on
control ring 1
SCADA ring 2
is used
SCADA ring 2
is used
OK
Quantum cable break on
both control rings
Quantum
switchover
Quantum
switchover
OK
Cable break on field
network (DIO clouds)
Quantum
switchover
Quantum
switchover
OK
I/O server A down
I/O server
switchover
I/O server
switchover
OK
Port A1 cable break
Server A switches
to ring 2
Server A switches
to ring 2
OK
Power supply down on
server A
SCADA server
switchover
SCADA server
switchover
OK
Server A is down and port
B1 cable break
Server B switches
to ring 2
Server B switches
to ring 2
OK
106
6-Validation
6.2. Performance tests
In this section we cover the performance tests we executed on our selected
architectures. Following is a list of our tests:
•
Impact of the application response time (ART)
•
The switchover time of the PAC units
Additional tools we used for our tests are:
•
Schneider Electric Modicon M340 PAC
DIG_OUT
This PAC is used with a digital I/O
•
module so that we can drive cable
breakers
Hilscher netAnalyzer
This device can analyze and record
Ethernet traffic, it can also manage
physical digital inputs and t is very
accurate – its time-stamp has a
resolution of 10 nanoseconds.
The table below shows the different parameters that were changed during our tests,
and the different values that we used:
Cyclic scan time (ms)
100
200
300
400
Data size (kB)
100
300
500
700
Architecture and
measurement type
RCE
EIO
RFD
EIO
RFD
DIO
RCE EIO: Redundant Compact Evolutive architecture, measurements done on Ethernet remote I/Os
RFD EIO: Redundant Flexible Distributed architecture, measurements done on Ethernet remote I/Os
RFD DIO: Redundant Flexible Distributed architecture, measurements done on Distributed I/Os
107
6-Validation
6.2.1. Hot Standby system application response time
The application response time (ART) is the time taken for information to be
recognized by the system, and then for the system to react. Following is a description
of the different steps of this measurement type:
A physical signal is sent
1
to the remote module
on a digital input; this is
the start time of the
DI signal
2
measurement
The remote module
sends the
Ethernet
transmission
corresponding
information to the
Quantum
The Quantum CPU
3
handles the input
information and sends
a command to an
output
Computation
4
The Quantum sends
the corresponding
Ethernet
transmission
information to the
remote module
5
The remote module
processes the physical
digital output; this is the
stop time of the
DO signal
measurement
The ART is the time taken for all the steps described in the table above to be
completed.
Note: In the table above, the remote module is represented as an Ethernet drop, but
the principle of the measurement is the same with distributed I/O modules or any
system with inputs and outputs. More specific figures for the tested hardware will be
described in the following sub-sections. All ART measurements are completed with
108
6-Validation
the Quantum A as the primary PAC, and the Quantum B as the standby PAC and
running. Each test was performed at least one thousand times.
Ethernet remote I/O ART with Redundant Compact Evolutive architecture
Using the Redundant Compact Evolutive architecture (the architecture without DIO)
and the Redundant Flexible Distributed architecture (the architecture with DIO,
although we did not use them for this test) we measured the ART with the digital input
and the digital output on drops, as shown in the following figure:
SW12
SW11
DIG_OUT
Optical fiber (10km)
DROP 4
CRA
CRA
DROP 1
DISTANT
DROPs
To Digital Input
LOCAL
DROPs
DROP 5
DROP 2
CRA
CRA
Start signal
Net Analyzer
DROP 3
DROP 6
CRA
CRA
Stop signal
From Digital Output
Distributed I/O ART with Redundant Flexible Distributed architecture
Using the Redundant Flexible Distributed architecture (the architecture with DIO
devices) we measured the ART with the digital input and the digital output on an STB,
as shown in the following figure:
DIG_IN
DIG_OUT
M340
STB 11
To Digital Input
STB 1
Start signal
DISTANT
DEVICES
LOCAL
DEVICES
STB 12
STB 2
STB 13
STB 3
Net Analyzer
STB 14
From Digital Output
STB 4
STB 15
Stop signal
STB 5
109
6-Validation
Theoretical maximum ART for QEIO solutions
The application response time is covered more specifically in a separate TVDA,
Quantum EIO design, that details the theoretical times. In this TVDA, we concentrate
our tests on the hot standby features.
In the first instance we can consider that:
Note: The added 32.596 is a constant value in milliseconds
representing the maximum network process time. This constant
applies to all our architectures.
A hot standby system has an extended cycle time because:
-
Extra time is needed for the data to transfer to the coprocessor ( which is
proportional to the data size)
-
Extra time might be needed if the coprocessor time is longer than the user
logic
More details on this topic are available in section 3.2.1.
Allowing for the above, the complete formula can be modified with:
Note: The orange text in this formula represents the extra time needed for the hot
standby feature. The green text represents the time linked to the MAST.
Therefore, we can deduce the total formula of the ART:
110
6-Validation
Below is a diagram of the different actions that explain some of the parameters of the
above formula:
input @CRP
output @CRP
input @CPU
CPU state
Quantum A
in acq
hsby
hsby
transfer
prog exec
out update
in acq
primary run
hsby
hsby
transfer
prog exec
out update
measurement
B
A
C
This diagram shows that, depending on the moment at which the input data arrives to
the PAC on the network, there can be up to two MAST cycles before the output is
sent to the network i.e. the data arrives at the CRP (A), it is stored in a buffer until the
next input acquisition cycle of the CPU (B). At the end of the MAST, the output is sent
to the CRP (C).
The RPI is the period at which the CRA sends the data to the CRP. Therefore the RPI
and the network transmission times are added to get the total maximum time.
Note: When using a DIO solution instead of Ethernet RIO, the ART is not guaranteed.
Therefore, there is no theoretical value.
Influence of different architectures
Below is a table summarizing the results of our ART tests – 1000 per configuration –
based on the relevant architecture, using a 200 ms cyclic scan time and 500 kB of
data:
System configuration
Architecture
I/O type
RCE
EIO
RFD
DIO
RPI
125
-
min time
225
236
228
calculated
ART Measurements
max time
avg. time max time std. dev.
dev. %
398
569
76
19
628
400
578
79
20
376
564
69
18
RCE: Redundant Compact Evolutive architecture
RFD: Redundant Flexible Distributed architecture
111
6-Validation
The measurements performed on the EIO are the same, so the presence of the DIO
clouds does not influence the performance of the EIO system.
The measurements performed on the DIO are slightly better because the repeating
time on the DIO is 62ms, which is shorter than the 125 ms RPI on the EIO.
In all cases, the measured standard deviation is about twenty percent. This means
that:
-
68% of the ART are between ART avg – 20% and ART avg + 20%
-
95% of the ART are between ART avg – 40% and ART avg + 40%
The next sections show this information in graphics.
Influence of scan time
Below are the results of our ART tests – 1000 per configuration – when considering
the influence of the scan time; these tests were performed on the RCE architecture
on EIO with 500 kB of data.
System configuration
Cyclic scan time
Watchdog
100
250
200
500
300
800
400
1200
RPI
62
125
200
300
min time
116
225
355
428
ART Measurements
avg. time max time std. dev.
208
309
40
398
569
76
579
807
103
756
1116
162
dev. %
19
19
18
21
calculated
max time
365
628
903
1203
1200
1000
ART (ms)
800
Average
Std. Dev.
600
2 x Std. Dev.
Calc. Max
400
200
0
100
200
300
400
cyclic scan time (ms)
The colored curves in the above graph correspond to the following:
-
The top red curve represents the calculated maximum ART
-
The middle orange curve shows the average measurement
112
6-Validation
-
The blue curves are one standard deviation distant from the average,
which is 68 per cent of the measurements are between these curves
-
The green curves are two standard deviations distant from the average,
which is 95 per cent of the measurements are between these curves
The system behaves as expected – the ART increases with the scan time and the
standard deviation is about twenty per cent.
Influence of data size
Below are the results of our ART tests – 1000 per configuration – when considering
the influence of the data size. These tests were performed on the RCE architecture
on EIO with a 100 ms cyclic scan time.
System
Data (kB)
100
300
500
700
min time
106
109
116
130
ART Measurements
avg. time max time std. dev.
184
260
35
196
279
36
208
309
40
224
318
48
calculated
max time
309
337
365
431
dev. %
19
18
19
21
500
450
400
ART (ms)
350
Average
300
Std. Dev.
250
2 x Std. Dev.
200
Calc. Max
150
100
50
0
100
300
500
700
data (kB)
The colored curves correspond to the following:
-
The top red curve represents the calculated maximum ART
-
The middle orange curve shows the average measurement
-
The blue curves are one standard deviation distant from the average,
which is 68 per cent of the measurements are between these curves
-
The green curves are two standard deviations distant from the average,
which is 95 per cent of the measurements are between these curves
113
6-Validation
The ART increases slightly with the increase in data size. This is due to copying of
the data to the coprocessor, which takes 7 ms per 100 kB. The increase in time is
more for the last measurement; however this is to be expected as when the data
amount is above 600 kB the coprocessor needs more than 100 ms to send the data
to the hot standby Quantum. For more information on this see section 3.2.1.
ART test results analysis
The ART results comply with our previous conclusions:
-
ART does not depend on the architecture
-
ART increases with the scan time
-
ART increases slightly with the data size
Note: All our tests had a standard deviation of about twenty per cent.
6.2.2. Application response time with switchover
In this section, the ART is measured with random switchovers forced by the
application. For these tests we used the Redundant Compact Evolutive architecture.
The maximum measurement represents the longest time between an input and the
corresponding reaction in the system when an applicative switchover occurs.
When conucting these tests, we measured the ART with switchover as follows:
-
The ART measurement is performed with the same method as in the
previous section 6.2.1
-
Every 30 seconds, the primary Quantum switches to offline mode using
the system words described in section 3.2.3
However, this test does measure the ART many times without including the
switchover, which is for two reasons:
-
The ART runs every second, while the switchover is ordered only every
thirty seconds
-
When the switchover occurs, it does not always make the ART longer as it
depends when the switchover occurs within the application, i.e. at which
time within the ART the switchover occurs.
Therefore, the maximum ART is the most important piece of information for us here.
114
6-Validation
The theoretical maximum value of the ART with switchover can be calculated as
follows:
Therefore:
Note: The added 32.596 is a constant value in milliseconds representing the
maximum network process time. This constant applies to all our architectures.
The cycle time is influenced by the data size according to the following formula:
Therefore, the complete formula is the as follows:
Note: The orange text in this formula represents the extra time needed by the hot
standby feature. The green text represents the time linked to the MAST.
In the Appendix of this document, you will find a diagram that shows the different
actions that occur on the Quantum side during this test, i.e. the data arrives at the
CRP (A) and it is stored in a buffer until the next input acquisition cycle of the CPU
(B). The RPI and network transmission time do not appear on this diagram.
Below are the results of our tests – more than 50 switchovers per configuration – with
a fixed data exchange of 500 kB:
System configuration
Cyclic scan time
Watchdog
100
250
200
500
300
800
RPI
62
125
200
measured
max time
478
877
1197
calculated
max time
635
1098
1573
115
6-Validation
1200
ART with switchover (ms)
1000
800
600
400
200
0
100
200
300
cyclic scan tim e (m s)
The ART increases with the scan time, which was the expected result. In addition, our
results were always below the maximum calculated value.
6.2.3. Switchover forced by the application
In this section, the test intends to measure the time where the outputs are not
refreshed during a switchover. This is useful for configuring the holdup time for the
remote I/Os, i.e. the holdup time should be set accordingly so that the I/Os do not
switch to their fallback values. However, the holdup time should also be as small as
possible in order to react quickly to system failures.
The test was performed as follows:
•
•
Two digital outputs are set at different CPU cycles
o
At cycle 1 output A is set
o
At cycle 2 output B is also set
o
At cycle 3 the two outputs are reset
The measurement starts at the rising edge of output A and stops at the rising
edge of output B and the measurement is performed by the NetAnalyzer
•
Switchovers are forced randomly by the application
116
6-Validation
Network outputput A
Network output B
Measurement
Following is the associated SFC:
0
Output_A=1
Output_B=0
Output_A . / Output_B
1
Output_A=1
Output_B=1
Output_A . Output_B
2
Output_A=0
Output_B=0
/ Output_A . / Output_B
This test takes many measurements without switchover as the switchover does not
always make the measurement longer because it depends when the switchover
occurs within the application, i.e. at which point in the SFC the switchover occurs.
Therefore, the maximum time is the most important piece of information for us here.
Using Ethernet remote I/O
Using the Redundant Compact Evolutive architecture (the architecture without DIO)
and the Redundant Flexible Distributed architecture (the architecture with DIO
although we do not use them for this test) we measured the switchover time with the
two selected outputs on a drop. They are hardwired to the NetAnalyzer.
117
6-Validation
SW12
CRA
DROP 4
DISTANT
DROPs
CRA
DROP 5
CRA
DROP 6
From Digital Output A
From Digital Output B
Net Analyzer
Stop signal
Start signal
Using Distributed I/O
Using the Redundant Flexible Distributed architecture (the architecture with DIO) we
measured the switchover time the same way as with our two I/Os on a STB.
STB 11
172.20.130.64
DISTANT
DEVICES
STB 12
172.20.130.65
SW10
STB 13
172.20.130.66
STB 14
172.20.130.67
From Digital Output A
STB 15
172.20.130.68
From Digital Output B
Net Analyzer
Stop signal
Start signal
118
6-Validation
Theoretical switchover time forced by the application
The theoretical value is calculated as follows:
Therefore
Note: The added 16.298 is a constant value in milliseconds representing the
maximum network process time. This constant applies to all our architectures.
The cycle time is influenced by the data size according to the following formula:
Therefore, the complete formula is the following:
Note: The orange text in this formula represents the extra time needed by the hot
standby feature. The green text represents the time linked to the MAST.
In the Appendix of this document, you will find a diagram that shows the different
actions that occur on the Quantum side during this test. The RPI and network
transmission time do not appear on this diagram.
Note: When using a DIO solution instead of Ethernet RIO, the ART cannot be
guaranteed, therefore there is no theoretical value.
119
6-Validation
Switchover forced by application results analysis
The table below summarizes our measurements – more than 50 switchovers per
configuration – regarding the influence of the scan time with a fixed data size of 500
kB:
System configuration
Cyclic scan time
Watchdog
100
250
200
500
300
800
measured max switchover time
RCE EIO
RDF EIO
RFD DIO
372
364
938
569
575
1181
752
748
1600
RPI (EIO)
62
125
200
calculated
max time*
421
721
1021
* the calculated max time only applies to the measurements on EIO
RCE EIO: Redundant Compact Evolutive architecture, measurements done on Ethernet remote I/Os
RFD EIO: Redundant Flexible Distributed architecture, measurements done on Ethernet remote I/Os
RFD DIO: Redundant Flexible Distributed architecture, measurements done on Distributed I/Os
RCE EIO
RDF EIO
RFD DIO
applicative switchover time (ms)
1500
1000
500
0
100
200
300
cyclic scan tim e (m s)
It is clear that the EIO solutions perform a lot better than the DIO solution when
switchover is commanded by the application. However, the presence of the DIO does
not change the performance on the QEIO system. In addition, the switchover time
increases with the scan time, which is the expected behavior and our results were
always below the maximum calculated value.
6.2.4. Switchover due to loss of power supply
In this section, the switchover time measurements are shown for situations where the
switchover is forced because of a loss of power supply to the primary Quantum.
Each configuration was tested 100 times.
120
6-Validation
Using Ethernet remote I/O
Using the Redundant Compact Evolutive architecture (the architecture without DIO)
and the Redundant Flexible Distributed architecture (the architecture with DIO,
although we do not use them for this test) we measured the switchover time as
follows:
-
The M340 sets a digital output to start the measurement, which is
hardwired to a breaker that shuts down the power supply of the primary
Quantum
-
After the switchover the new primary Quantum sets a digital output from a
drop of which the signal then stops the measurement
CRP
NOE3
NOE1
CRP
NOE3
NOE2
NOE1
F.O.
NOE2
!! New Primary !!
SWITCHOVER
STANDBY QUANTUM
PRIMARY QUANTUM
Power Supply OFF
M340
DIG_OUT
SW12
CRA
DROP 4
DISTANT
DROPs
CRA
DROP 5
Start signal
DROP 6
Stop signal
CRA
Net Analyzer
From Digital Output
Using Distributed I/O
Using the Redundant Flexible Distributed architecture (the architecture with DIO) we
measured the switchover time as follows:
121
6-Validation
-
The M340 sets a digital output to start the measurement, which is
hardwired to a breaker that shuts down the power supply of the primary
Quantum
-
After the switchover the new primary Quantum sets a digital output from a
STB of which the signal then stops the measurement.
CRP
NOE3
NOE1
CRP
NOE3
NOE2
NOE1
F.O.
NOE2
!! New Primary !!
SWITCHOVER
STANDBY QUANTUM
PRIMARY QUANTUM
Power Supply OFF
DIG_OUT
M340
STB 11
172.20.130.64
DISTANT
DEVICES
Start signal
STB 12
172.20.130.65
STB 13
172.20.130.66
Net Analyzer
STB 14
172.20.130.67
Stop signal
From Digital Output
STB 15
172.20.130.68
122
6-Validation
Theoretical switchover time due to loss of power supply
The theoretical maximum value is calculated as follows:
Therefore
Note: The added 16.298 is a constant value in milliseconds representing the
maximum network process time. This constant applies to all our architectures.
The cycle time is influenced by the data size according to the following formula:
Therefore, the complete formula is the following:
Note: The orange text or this formula represents the extra time needed by the hot
standby feature. The green text represents the time linked to the MAST.
In the Appendix of this document, you will find a diagram that shows the different
actions that occur on the Quantum side during this test. The RPI and network
transmission time do not appear on this diagram.
Note: When using a DIO solution instead of Ethernet RIO, the ART cannot be
guaranteed, therefore there is no theoretical value.
Influence of the scan time
Below is a table summarizing our measurements – 100 switchovers per configuration
– regarding the influence of the scan time with a fixed data size of 500 kB:
System configuration
Cyclic scan time
Watchdog
100
400
200
700
300
1100
RPI (EIO)
100
175
275
measured max switchover time
RCE EIO
RDF EIO
RFD DIO
491
492
983
583
596
1372
667
684
1905
calculated
max time*
821
1421
2121
* the calculated max time only applies to the measurements on EIO
RCE EIO: Redundant Compact Evolutive architecture, measurements done on Ethernet remote I/Os
RFD EIO: Redundant Flexible Distributed architecture, measurements done on Ethernet remote I/Os
RFD DIO: Redundant Flexible Distributed architecture, measurements done on Distributed I/Os
123
6-Validation
RCE EIO
RDF EIO
RFD DIO
power switchover time (ms)
2000
1500
1000
500
0
100
200
300
cyclic scan tim e (m s)
It is clear that the EIO solutions perform a lot better than the DIO solution when the
switchover is due to a loss of power supply. However, the presence of the DIO does
not change the performance on the QEIO system.
The switchover time increases with the scan time, which is the expected behavior. All
our EIO measurements were a lot better than the maximum theoretical value, which is
due to the fact that the absence of the CRP is detected by the standby Quantum
before the watchdog runs out of time.
Influence of the data size
Below is a table summarizing our measurements – 100 switchovers per configuration
– regarding the influence of the data size with a fixed cyclic scan time of 100 ms:
System
Data (kB)
100
300
500
measured max switchover time
RCE EIO
RDF EIO
RFD DIO
490
493
1132
494
493
1256
491
492
983
calculated
max time*
737
779
821
* the calculated max time only applies to the measurements on EIO
RCE EIO: Redundant Compact Evolutive architecture, measurements done on Ethernet remote I/Os
RFD EIO: Redundant Flexible Distributed architecture, measurements done on Ethernet remote I/Os
RFD DIO: Redundant Flexible Distributed architecture, measurements done on Distributed I/Os
124
6-Validation
RCE EIO
RDF EIO
RFD DIO
1400
power switchover time (ms)
1200
1000
800
600
400
200
0
100
300
500
data (kB)
Once again, the EIO solutions perform a lot better than the DIO solution. Both EIO
measurements have the same performance, so DIO clouds have no negative effect
on the EIO system. In addition, the data size does not have any visible influence on
these measurements.
Switchover due to loss of power supply results analysis
When the switchover is trigged because of a loss of power supply, the time for the
standby Quantum to take control is mainly influenced by the scan time. This time has
always been measured as less than 700 ms with our configurations (up to 300 ms
scan time and 700 kB of data). However, the maximum value could easily reach more
than two seconds, so the system must be carefully considered if loss of power on the
primary Quantum is a key factor. Our results were always below the maximum
calculated value.
125
6-Validation
6.2.5. Switchover due to field network loss
This test intends to measure the switchover time in the case of the loss of field
network. We used the same application as used for the applicative switchover
measurements, however in this instance the switchover is not triggered by the
application, but by a network error.
The initial state of our test is a degraded state – the cable between the primary
Quantum and the ConneXium switch SW7 is unplugged so only one branch of the
field network main loop is active. The cable between the primary Quantum and the
ConneXium switch SW11 is then cut randomly using a cable breaker driven by a
M340 PLC. Therefore, the most interesting measurement is the maximum value.
This test was performed using QEIO on the Redundant Compact Evolutive
CRP
NOE3
STANDBY QUANTUM
PRIMARY QUANTUM
SW8
SW7
Network
cable
breaker
NOE2
NOE1
CRP
NOE3
NOE2
NOE1
architecture. The following figure summarizes the test:
SW12
SW11
DROP 4
CRA
CRA
DROP 1
DROP 5
CRA
CRA
DROP 2
DROP 6
CRA
DROP 3
CRA
DIG_OUT
M340
From Digital Output A
From Digital Output B
Stop signal
Start signal
126
6-Validation
The theoretical maximum value should be the same as in the previous test for the
switchover time due to loss of power supply, which is represented by the following
equation:
Below is a table of the test results for more than 50 switchovers:
Cyclic scan time
200
System configuration
Watchdog
RPI
500
125
Data (kB)
500
measured max
switchover time
624
calculated
max time
1221
It is important to note that the measured time is lower than the maximum theoretical
value. As previously mentioned for the loss of power supply test, the result is very
good as the absence of the CRP is detected by the standby Quantum before the
watchdog runs out of time.
6.2.6. Performance tests conclusion
Our performance tests all passed – the measured times were always lower than the
calculated maximum limit. The table below shows the effect of a change of cyclic
scan time from 100 ms to 300 ms on all the tests on a Redundant Compact Evolutive
architecture. This table also shows the effect of a change of data size from 100 kB to
300 kB.
test (RCE architecture)
hot standby ART
ART with switchover
applicative switchover time
power switchover time
cyclic scan 100 to 300 ms
data = 500 kB
measured
calculated
x 2.78
x 2.47
x 2.50
x 2.48
x 2.02
x 2.43
x 1.36
x 2.58
data 100 to 300 kB
cyclic scan = 100 ms
measured
calculated
+ 6.52 %
+ 9.06 %
+ 0.82 %
+ 5.70 %
127
6-Validation
This table shows that the scan time has a much greater effect on the system
response time and switchover time, than that of the data size of the program. As
shown in the table, less than ten per cent extra time is added if the data size varies
from 100 kB to 300 kB for a 100 ms cyclic scan time.
According to our tests, the architecture (Redundant Compact Evolutive or Redundant
Flexible Distributed) does not have any visible effect on the performance. If the
system has a lot of Ethernet traffic, the extra 16 ms we added for each information
transfer makes up for the difference in the calculated formulas.
The I/O system (Distributed I/O or Ethernet Remote I/O) does not change the results
of the nominal (i.e. without disturbance) Application Response Time and in case of
switchover the QEIO solution performs a lot better than the DIO solution.
128
6-Validation
129
7-Conclusion
7. Conclusion
A high availability automation system is able to support a lot of disturbance without
causing the system to go offline. This means highly available automation systems
have a high resilience to failures – PACs and their modules, network, power loss, and
so on – and also assist with seamless maintenance operations, i.e. the maintenance
teams can perform maintenance operations while the redundant hardware controls
the system.
Our performance tests show that a hot standby QEIO solution performs as well as a
DIO solution in nominal mode, but but with much more efficient bandwidth
management and determinism; furthermore, the QEIO solution performs a lot better in
the case of a switchover.
According to our tests, the selected architectures meet the expected customer
challenges noted at the start of this document:
•
Providing a high level of availability and reliability
•
Having a short recovery following system unavailability
•
Fast switchover times
•
Multiple levels of redundancy ensuring maintainability
•
Providing a system with remote I/O management for large scale plants (as
needed by tunneling or mining industries, for example)
130
7-Conclusion
131
8-Appendix
8. Appendix
8.1. SCADA configuration
8.1.1. OFS configuration
Schneider Electric’s OPC Factory Server (OFS) is a software package that can
exchange data with PAC units and share that data with other applications. In our
case, OFS is a link between the Quantum PAC units and Vijeo Citect, using the
OFSOPC protocol.
Below is the step-by-step configuration of OFS:
Step
Action
Device Alias: OFS_QUANTUM_1
Create a New Device Alias ‘OFS_QUANTUM_1’, which allows for communication
between the NOE1 and the SCADA system
1
132
8-Appendix
Step
Action
Device address
• On the line ‘Device Address’, click the square on the right.
2
• In the PLCs area, select UNITY
• Set the IP address as 172.20.110.110
Click OK
133
8-Appendix
Step
Action
Data Dictionary
To access PAC data OFS uses the Data Dictionary. This option allows OFS to
automatically resynchronize the addresses of the variables in the case of inconsistency
3
following an online modification to an pplication
Save Configuration
4
From the File menu, click on Save Application item
Device Alias: OFS_QUANTUM_2
Create a New Device Alias ‘OFS_QUANTUM_2’ which allows for communication
between the NOE2 and the SCADA with the IP address 172.20.120.120
Repeat steps 1 to 4 for this alias.
5
134
8-Appendix
8.1.2. SCADA Servers Configuration
We use Citect Project Editor to perform the following different server configuration
steps:
• Creation of a cluster
• Servers mapping
• Creation of the I/O and ATR servers
Cluster: Q_EIO
Server A
Server B
IO_SERV_A
ALARM_SERVER_A
TREND_SERVER_A
REPORT_SERVER_A
IO_SERV_B
ALARM_SERVER_B
TREND_SERVER_B
REPORT_SERVER_B
PRIMARY_SERV_A1
STANDBY_SERV_A2
STANDBY_SERV_B1
STANDBY_SERV_B2
172.20.110.1
172.20.120.1
172.20.110.2
172.20.120.2
In Citect Project Editor, click the Servers menu to select the appropriate items to
configure:
135
8-Appendix
Cluster
From the Servers menu, click on Clusters and create a cluster called ‘Q_EIO’
Ckick Add to complete the creation of the cluster.
136
8-Appendix
Servers
As described in the Design chapter, we use a Primary and a Standby server, each
connected to two networks. Still in the Servers menu, click on Network Addresses
and create four server addresses with the following parameters:
Step
Action
Server A1 (Primary server on ring network 1): IP Address: 172.20.110.1
Cluster: Q_EIO
1
Server A
Server B
IO_SERV_A
ALARM_SERVER_A
TREND_SERVER_A
REPORT_SERVER_A
IO_SERV_B
ALARM_SERVER_B
TREND_SERVER_B
REPORT_SERVER_B
PRIMARY_SERV_A1
STANDBY_SERV_A2
STANDBY_SERV_B1
STANDBY_SERV_B2
172.20.110.1
172.20.120.1
172.20.110.2
172.20.120.2
Click Add to complete the configuration of this server.
137
8-Appendix
Step
Action
Server A2 (Standby server on ring network 2): IP Address: 172.20.120.1
Cluster: Q_EIO
2
Server A
Server B
IO_SERV_A
ALARM_SERVER_A
TREND_SERVER_A
REPORT_SERVER_A
IO_SERV_B
ALARM_SERVER_B
TREND_SERVER_B
REPORT_SERVER_B
PRIMARY_SERV_A1
STANDBY_SERV_A2
STANDBY_SERV_B1
STANDBY_SERV_B2
172.20.110.1
172.20.120.1
172.20.110.2
172.20.120.2
Click Add to complete the configuration of this server.
138
8-Appendix
Step
Action
Server B1 (Standby server on ring network 1): IP Address: 172.20.110.2
Cluster: Q_EIO
3
Server A
Server B
IO_SERV_A
ALARM_SERVER_A
TREND_SERVER_A
REPORT_SERVER_A
IO_SERV_B
ALARM_SERVER_B
TREND_SERVER_B
REPORT_SERVER_B
PRIMARY_SERV_A1
STANDBY_SERV_A2
STANDBY_SERV_B1
STANDBY_SERV_B2
172.20.110.1
172.20.120.1
172.20.110.2
172.20.120.2
Click Add to complete the configuration of this server.
139
8-Appendix
Step
Action
Server B2 (Standby server on ring network 2): IP Address: 172.20.120.2
Cluster: Q_EIO
4
Server A
Server B
IO_SERV_A
ALARM_SERVER_A
TREND_SERVER_A
REPORT_SERVER_A
IO_SERV_B
ALARM_SERVER_B
TREND_SERVER_B
REPORT_SERVER_B
PRIMARY_SERV_A1
STANDBY_SERV_A2
STANDBY_SERV_B1
STANDBY_SERV_B2
172.20.110.1
172.20.120.1
172.20.110.2
172.20.120.2
Click Add to complete the configuration of this server.
Alarm/Trend/Report (ATR) Servers
Once the servers are created, we can create Primary and Standby ATR servers.
Each ATR server is related to a cluster, two network addresses (Server A1 and
Server A2, or Server B1 and Server B2) and an operational mode (Primary or
Standby).
From the Servers menu, select Alarm Servers.
140
8-Appendix
Step
Action
Alarm server A (Primary Server):
Cluster Name: Q_EIO
Server Name: ALARM_SERVER_A
Network Addresses: PRIMARY_SERV_A1,STANDBY_SERV_A2
Mode: Primary
Cluster: Q_EIO
1
Server A
Server B
IO_SERV_A
ALARM_SERVER_A
TREND_SERVER_A
REPORT_SERVER_A
IO_SERV_B
ALARM_SERVER_B
TREND_SERVER_B
REPORT_SERVER_B
PRIMARY_SERV_A1
STANDBY_SERV_A2
STANDBY_SERV_B1
STANDBY_SERV_B2
172.20.110.1
172.20.120.1
172.20.110.2
172.20.120.2
Click Add to complete the creation of alarm server A.
141
8-Appendix
Step
Action
Alarm server B (Standby Server):
Cluster Name: Q_EIO
Server Name: ALARM_SERVER_B
Network Addresses: PRIMARY_SERV_B1,STANDBY_SERV_B2
Mode: Standby
Cluster: Q_EIO
Server A
Server B
IO_SERV_A
ALARM_SERVER_A
TREND_SERVER_A
REPORT_SERVER_A
IO_SERV_B
ALARM_SERVER_B
TREND_SERVER_B
REPORT_SERVER_B
2
PRIMARY_SERV_A1
STANDBY_SERV_A2
STANDBY_SERV_B1
STANDBY_SERV_B2
172.20.110.1
172.20.120.1
172.20.110.2
172.20.120.2
Click Add to complete the creation of alarm server B.
Trends and reports servers
Proceed in the same way for the Reports and Trends servers (Report A, Report B, Trend A and
Trend B). Server A is always the primary server and server B is the standby server.
Cluster: Q_EIO
Server A
Server B
IO_SERV_A
ALARM_SERVER_A
TREND_SERVER_A
REPORT_SERVER_A
IO_SERV_B
ALARM_SERVER_B
TREND_SERVER_B
REPORT_SERVER_B
3
PRIMARY_SERV_A1
STANDBY_SERV_A2
STANDBY_SERV_B1
STANDBY_SERV_B2
172.20.110.1
172.20.120.1
172.20.110.2
172.20.120.2
142
8-Appendix
I/O Servers
Like ATR servers, I/O servers are also related to a cluster and two network addresses
(Server A1 and Server A2, or Server B1 and Server B2).
From the Servers menu, select I/O Servers.
Step
Action
I/O Server A (Primary I/O Server)
Cluster Name: Q_EIO
Server Name: IO_SERV_A
Network Addresses: PRIMARY_SERV_A1,STANDBY_SERV_A2
Cluster: Q_EIO
1
Server A
Server B
IO_SERV_A
ALARM_SERVER_A
TREND_SERVER_A
REPORT_SERVER_A
IO_SERV_B
ALARM_SERVER_B
TREND_SERVER_B
REPORT_SERVER_B
PRIMARY_SERV_A1
STANDBY_SERV_A2
STANDBY_SERV_B1
STANDBY_SERV_B2
172.20.110.1
172.20.120.1
172.20.110.2
172.20.120.2
Click Add to complete the creation of I/O server A.
143
8-Appendix
Step
Action
I/O Server B (Standby I/O Server)
Cluster Name: Q_EIO
Server Name: IO_SERV_B
Network Addresses: PRIMARY_SERV_B1,STANDBY_SERV_B2
Cluster: Q_EIO
2
Server A
Server B
IO_SERV_A
ALARM_SERVER_A
TREND_SERVER_A
REPORT_SERVER_A
IO_SERV_B
ALARM_SERVER_B
TREND_SERVER_B
REPORT_SERVER_B
PRIMARY_SERV_A1
STANDBY_SERV_A2
STANDBY_SERV_B1
STANDBY_SERV_B2
172.20.110.1
172.20.120.1
172.20.110.2
172.20.120.2
Click Add to complete the creation of I/O server B.
8.1.3. Communication Configuration
Communication configuration consists of set up for boards, ports and I/O devices.
The diagram below illustrates the communication path principle between the SCADA
system and an I/O Device.
144
_S
0
_
S
_S
0
0
_
S
_S
0
0
_
S
8-Appendix
_S
_
0
0
BOARD
BOARD
BOARD_A
BOARD_B
OFS – OFSOPC
OFS – OFSOPC
0
PORT 1
PORT 2
PORT 1
PORT 2
PORT1_BOARD_A
OFS_QUANTUM_1
PORT2_BOARD_A
OFS_QUANTUM_2
PORT1_BOARD_B
OFS_QUANTUM_1
PORT2_BOARD_B
OFS_QUANTUM_2
NOE 1
NOE 2
NOE 1
NOE 2
Primary
Standby
Standby
Standby
Priority 1
Priority 2
Priority 3
Priority 4
I/O Device
IO_DEVICE_QUANT
Note: The Express Wizard can make the configuration for a full setup easier, but it
does not manage the dual attachment redundant Quantum correctly, so we have not
used it in this document.
In Citect Project Editor, click the Communication menu to select the appropriate items
to configure:
Boards Configuration
The component board is used to declare the communication type (TCP/IP, OPC and
so on) used by the network components of the physical server.
The configuration of the redundant SCADA system requires two boards to be
configured – one for I/O server A and another for I/O server B. Both boards must be
of the type OFSOPC.
145
8-Appendix
Step
Action
Board A on I/O Server A
Board Name: Board_A
_S
_
Board Type: OFSOPC
Address: 0
1
0
S
_S
0
0
S
_
_S
0
0
_
S
_S
0
0
BOARD
BOARD
BOARD_A
BOARD_B
OFS – OFSOPC
OFS – OFSOPC
_
0
PORT 1
PORT 2
PORT 1
PORT 2
PORT1_BOARD_A
OFS_QUANTUM_1
PORT2_BOARD_A
OFS_QUANTUM_2
PORT1_BOARD_B
OFS_QUANTUM_1
PORT2_BOARD_B
OFS_QUANTUM_2
NOE 1
NOE 2
NOE 1
NOE 2
Primary
Standby
Standby
Standby
Priority 1
Priority 2
Priority 3
Priority 4
I/O Device
IO_DEVICE_QUANT
Click Add to complete the configuration of board A.
146
8-Appendix
Step
Action
Board B on I/O Server B
Board Name: Board_B
_S
_
Board Type: OFSOPC
Address: 0
2
0
S
_S
0
0
S
_
_S
0
0
_
S
_S
0
0
BOARD
BOARD
BOARD_A
BOARD_B
OFS – OFSOPC
OFS – OFSOPC
_
0
PORT 1
PORT 2
PORT 1
PORT 2
PORT1_BOARD_A
OFS_QUANTUM_1
PORT2_BOARD_A
OFS_QUANTUM_2
PORT1_BOARD_B
OFS_QUANTUM_1
PORT2_BOARD_B
OFS_QUANTUM_2
NOE 1
NOE 2
NOE 1
NOE 2
Primary
Standby
Standby
Standby
Priority 1
Priority 2
Priority 3
Priority 4
I/O Device
IO_DEVICE_QUANT
Click Add to complete the configuration of board B.
147
8-Appendix
Ports Configuration
The component port represents the link between the SCADA system and the I/O
Device.
A redundant SCADA system with double attachment requires two ports to be
configured for each I/O server. With our architecture, this means two ports on board A
for the I/O server A, and two ports on board B for I/O server B.
148
8-Appendix
Step
Action
Port 1 on I/O Server A
Port Name: PORT1_BOARDA
_S
_
Board Name: BOARD_A
Port Number: 10
1
S
_S
0
0
_
S
_S
0
0
_
S
_S
0
0
BOARD
BOARD
BOARD_A
BOARD_B
OFS – OFSOPC
OFS – OFSOPC
_
0
PORT 1
PORT 2
PORT 1
PORT 2
PORT1_BOARD_A
OFS_QUANTUM_1
PORT2_BOARD_A
OFS_QUANTUM_2
PORT1_BOARD_B
OFS_QUANTUM_1
PORT2_BOARD_B
OFS_QUANTUM_2
NOE 1
NOE 2
NOE 1
NOE 2
Primary
Standby
Standby
Standby
Priority 1
Priority 2
Priority 3
Priority 4
I/O Device
IO_DEVICE_QUANT
Click Add to complete the configuration of port 1 for I/O server A.
Note: The port number is 1 on all the ports; the port name is different on the port configurations.
149
8-Appendix
Step
Action
Port 2 on I/O Server A
Port Name: PORT2_BOARDA
_S
_
Board Name: BOARD_A
Port Number: 10
2
S
_S
0
0
_
S
_S
0
0
_
S
_S
0
0
BOARD
BOARD
BOARD_A
BOARD_B
OFS – OFSOPC
OFS – OFSOPC
_
0
PORT 1
PORT 2
PORT 1
PORT 2
PORT1_BOARD_A
OFS_QUANTUM_1
PORT2_BOARD_A
OFS_QUANTUM_2
PORT1_BOARD_B
OFS_QUANTUM_1
PORT2_BOARD_B
OFS_QUANTUM_2
NOE 1
NOE 2
NOE 1
NOE 2
Primary
Standby
Standby
Standby
Priority 1
Priority 2
Priority 3
Priority 4
I/O Device
IO_DEVICE_QUANT
Click Add to complete the configuration of port 2 for I/O server A.
150
8-Appendix
Step
Action
_S
0
_
S
_S
0
0
_
S
_S
0
0
Repeat the same operations for ports 1 and 2 of board B
_
S
_S
0
0
BOARD
BOARD
BOARD_A
BOARD_B
OFS – OFSOPC
OFS – OFSOPC
_
0
PORT 1
PORT 2
PORT 1
PORT 2
PORT1_BOARD_A
OFS_QUANTUM_1
PORT2_BOARD_A
OFS_QUANTUM_2
PORT1_BOARD_B
OFS_QUANTUM_1
PORT2_BOARD_B
OFS_QUANTUM_2
NOE 1
NOE 2
NOE 1
NOE 2
Primary
Standby
Standby
Standby
Priority 1
Priority 2
Priority 3
Priority 4
I/O Device
IO_DEVICE_QUANT
3
151
8-Appendix
I/O Devices Configuration
Four I/O devices must be defined – two for I/O server A and two for I/O server B. The
I/Odevices all have the same name because they are supposed to address the
same PAC.
When configuring a redundant SCADA system, there are three parameters which are
particularly important to configure:
•
Startup mode defines the initial state of the configured I/O device (primary or
standby)
•
Priority determines the switch order of the configured I/O devices
•
Address is filled in with the aliases defined in OFS: OFS_Quantum_1 or
OFS_Quantum_2
Note: Only one I/O device is to be configured as primary, all the other I/O devices will
be configured as standby. The primary server should have its priority set to 1.
Step
Action
152
8-Appendix
Step
Action
I/O Server A: Primary I/O Device with priority 1
Name: IO_DEVICE_QUANT
Number: 1
Address: OFS_QUANTUM_1
Protocol: OFSOPC
Port Name: PORT1_BOARDA
_S
_
Startup Mode: Primary
Priority: 1
1
0
S
_S
0
0
_
S
_S
0
0
_
S
_S
0
0
BOARD
BOARD
BOARD_A
BOARD_B
OFS – OFSOPC
OFS – OFSOPC
_
0
PORT 1
PORT 2
PORT 1
PORT 2
PORT1_BOARD_A
OFS_QUANTUM_1
PORT2_BOARD_A
OFS_QUANTUM_2
PORT1_BOARD_B
OFS_QUANTUM_1
PORT2_BOARD_B
OFS_QUANTUM_2
NOE 1
NOE 2
NOE 1
NOE 2
Primary
Standby
Standby
Standby
Priority 1
Priority 2
Priority 3
Priority 4
I/O Device
IO_DEVICE_QUANT
Click Add to complete the configuration of this I/O device.
153
8-Appendix
Step
Action
I/O Server A: Standby I/O Device with priority 2
Name: IO_DEVICE_QUANT
Number: 1
Address: OFS_QUANTUM_2
Protocol: OFSOPC
Port Name: PORT2_BOARDA
_S
_
Startup Mode: Standby
Priority: 2
2
0
S
_S
0
0
_
S
_S
0
0
_
S
_S
0
0
BOARD
BOARD
BOARD_A
BOARD_B
OFS – OFSOPC
OFS – OFSOPC
_
0
PORT 1
PORT 2
PORT 1
PORT 2
PORT1_BOARD_A
OFS_QUANTUM_1
PORT2_BOARD_A
OFS_QUANTUM_2
PORT1_BOARD_B
OFS_QUANTUM_1
PORT2_BOARD_B
OFS_QUANTUM_2
NOE 1
NOE 2
NOE 1
NOE 2
Primary
Standby
Standby
Standby
Priority 1
Priority 2
Priority 3
Priority 4
I/O Device
IO_DEVICE_QUANT
Click Add to complete the configuration of this I/O device.
154
8-Appendix
Step
Action
I/O Server B: Standby I/O Device with priority 3
Name: IO_DEVICE_QUANT
Number: 1
Address: OFS_QUANTUM_1
Protocol: OFSOPC
Port Name: PORT1_BOARDB
_S
_
Startup Mode: Standby
Priority: 3
3
0
S
_S
0
0
_
S
_S
0
0
_
S
_S
0
0
BOARD
BOARD
BOARD_A
BOARD_B
OFS – OFSOPC
OFS – OFSOPC
_
0
PORT 1
PORT 2
PORT 1
PORT 2
PORT1_BOARD_A
OFS_QUANTUM_1
PORT2_BOARD_A
OFS_QUANTUM_2
PORT1_BOARD_B
OFS_QUANTUM_1
PORT2_BOARD_B
OFS_QUANTUM_2
NOE 1
NOE 2
NOE 1
NOE 2
Primary
Standby
Standby
Standby
Priority 1
Priority 2
Priority 3
Priority 4
I/O Device
IO_DEVICE_QUANT
Click Add to complete the configuration of this I/O device.
155
8-Appendix
Step
Action
I/O Server B: Standby I/O Device with priority 4
Name: IO_DEVICE_QUANT
Number: 1
Address: OFS_QUANTUM_2
Protocol: OFSOPC
Port Name: PORT2_BOARDB
_S
_
Startup Mode: Standby
Priority: 4
4
0
S
_S
0
0
_
S
_S
0
0
_
S
_S
0
0
BOARD
BOARD
BOARD_A
BOARD_B
OFS – OFSOPC
OFS – OFSOPC
_
0
PORT 1
PORT 2
PORT 1
PORT 2
PORT1_BOARD_A
OFS_QUANTUM_1
PORT2_BOARD_A
OFS_QUANTUM_2
PORT1_BOARD_B
OFS_QUANTUM_1
PORT2_BOARD_B
OFS_QUANTUM_2
NOE 1
NOE 2
NOE 1
NOE 2
Primary
Standby
Standby
Standby
Priority 1
Priority 2
Priority 3
Priority 4
I/O Device
IO_DEVICE_QUANT
Click Add to complete the configuration of this I/O device.
156
8-Appendix
8.2. Performance tests chronograms
ART with switchover
input @CRP
output @CRP
input @CPU
CPU state
Quantum A
CPU state
Quantum B
in acq
in acq
hsby
hsby
hsby
primary run
prog exec
transfer
prog exec
out update
in acq
out update
in acq
hsby
hsby
hsby
prog exec
transfer
prog exec
out update
in acq
out update
in acq
standby run
hsby
hsby
hsby
prog exec
transfer
prog exec
primary stop
out update
in acq
out update
in acq
hsby
hsby
hsby
prog exec
transfer
prog exec
out update
in acq
out update
in acq
hsby
hsby
hsby
prog exec
transfer
prog exec
primary run
out update
out update
measurement
primary CPU shutdown
B
A
A
B
C
D
E
-
CPU switchover
C
D
E
the input data arrives at the CRP
the primary CPU switchos to offline mode due to applicative request
the hot standby CPU detects the offline mode of the primary CPU and starts a switchover
when the switchover is finished, the new primary CPU takes the input data into account
the output data is sent to the drop
157
8-Appendix
applicative switchover
output A @CRP
output B @CRP
CPU state
Quantum A
CPU state
Quantum B
in acq
hsby
hsby
hsby
in acq
primary run
prog exec
transfer
prog exec
out update
in acq
out update
in acq
hsby
hsby
hsby
prog exec
transfer
prog exec
out update
in acq
out update
in acq
standby run
hsby
hsby
hsby
A
B
C
D
E
-
out update
in acq
hsby
hsby
hsby
prog exec
transfer
prog exec
out update
in acq
out update
in acq
hsby
hsby
hsby
prog exec
transfer
prog exec
primary run
B
D
C
the output A is sent to the drop with value 1 (output B is still at 0)
the primary CPU switchos to offline mode due to applicative request
the hot standby CPU detects the offline mode of the primary CPU and starts a switchover
the switchover is finished
the output B is sent to the drop with value 1 (output A is still at 1)
power Quantum A
output @CRP
Watchdog Qantum B
or CRP offline detect
CPU state
Quantum B
primary run
in acq
no power
hsby
hsby
transfer
prog exec
out update
in acq
standby run
hsby
hsby
transfer
prog exec
out update
in acq
hsby
hsby
transfer
prog exec
out update
in acq
primary run
hsby
hsby
transfer
prog exec
out update
measurement
A
CPU switchover
C
B
A
B
C
D
E
-
out update
E
power down switchover
CPU state
Quantum A
out update
measurement
CPU switchover
primary CPU shutdown
A
primary stop
out update
in acq
prog exec
transfer
prog exec
D
E
the primary Quantum power supply is stopped
the hot standby CPU starts its watchdog ; the switchover starts soon because the primary CRP is not present
the watchdog is elapsed
the switchover is finished
the output is sent to the drop with value 1
158
Schneider Electric Industries SAS
Head Office
35, rue Joseph Monier
Due to evolution of standards and equipment, characteristics indicated in texts and images
in this document are binding only after confirmation by our departments
92506 Rueil-Malmaison Cedex
FRANCE
www.schneider-electric.com
Print:
Version 1.00 – 10 2011