TVDA How Can I Implement M580 HSBY System V2

How Can I …
Implement an M580 Redundant

System? V2
Tested Validated Documented Architecture

High availability
Develop
your project
2
© 2017 Schneider Electric All Rights Reserved

Important information
People responsible for the application, implementation and use of this document must make sure
that all necessary design considerations have been taken into account and that all laws, safety
and performance requirements, regulations, codes, and applicable standards have been obeyed
to their full extent.
Schneider Electric provides the resources specified in this document. These resources can be
used to minimize engineering efforts, but the use, integration, configuration, and validation of the
system is the user’s sole responsibility. Said user must ensure the safety of the system as a
whole, including the resources provided by Schneider Electric through procedures that the user
deems appropriate.
Notice
This document is not comprehensive for any systems using the given architecture and does not
absolve users of their duty to uphold the safety requirements for the equipment used in their
systems, or compliance with both national or international safety laws and regulations.
Readers are considered to already know how to use the products described in this document.
This document does not replace any specific product documentation.
The following special messages may appear throughout this documentation or on the equipment
to warn of potential hazards or to call attention to information that clarifies or simplifies a
procedure.
The addition of this symbol to a Danger or Warning safety label indicates that an
electrical hazard exists, which will result in personal injury if the instructions are not
followed.
This is the safety alert symbol. It is used to alert you to potential personal injury hazards.
Obey all safety messages that follow this symbol to avoid possible injury or death.
DANGER
DANGER indicates an imminently hazardous situation which, if not avoided, will result in death
or serious injury.
Failure to follow these instructions will result in death or serious injury.

WARNING
WARNING indicates a potentially hazardous situation which, if not avoided, can result in death
or serious injury.
Failure to follow these instructions can cause death, serious injury or equipment
damage.
CAUTION
CAUTION indicates a potentially hazardous situation which, if not avoided, can result in minor
or moderate injury.
Failure to follow these instructions can result in injury or equipment damage.
NOTICE
NOTICE is used to address practices not related to physical injury.
Failure to follow these instructions can result in equipment damage.
Note: Electrical equipment should be installed, operated, serviced, and maintained only by
qualified personnel. No responsibility is assumed by Schneider Electric for any consequences
arising out of the use of this material.
A qualified person is one who has skills and knowledge related to the construction, operation and
installation of electrical equipment, and has received safety training to recognize and avoid the
hazards involved.
Before you begin

This automation equipment and related software is used to control a variety of industrial
processes. The type or model of automation equipment suitable for each application will vary
depending on factors such as the control function required, degree of protection required,
production methods, unusual conditions and government regulations etc. In some applications
more than one processor may be required when backup redundancy is needed.
Only the user can be aware of all the conditions and factors present during setup, operation and
maintenance of the solution. Therefore, only the user can determine the automation equipment
and the related safeties and interlocks which can be properly used. When selecting automation
and control equipment and related software for a particular application, the user should refer to

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.
WARNING
EQUIPMENT OPERATION HAZARD
 Follow all start up tests as recommended in the equipment documentation.
 Store all equipment documentation for future reference.
 Software testing must be done in both simulated and real environments.
damage.
Verify that the completed system is free from all short circuits and grounds, except those grounds
installed according to local regulations (according to the National Electrical Code in the USA, for
example). If high-potential voltage testing is necessary, follow recommendations in the equipment
documentation to prevent accidental equipment damage.
Before energizing equipment:
 Remove tools, meters, and debris from equipment
 Close the equipment enclosure door
 Remove ground from incoming power lines
 Perform all start-up tests recommended by the manufacturer

Operation and adjustments
The following precautions are from NEMA Standards Publication ICS 7.1-1995 (English version
prevails):
Regardless of the care exercised in the design and manufacture of equipment or in the selection
and rating of components; there are hazards that can be encountered if such equipment is
improperly operated.
It is sometimes possible to misadjust the equipment and thus produce unsatisfactory or unsafe
operation. Always use the manufacturer’s instructions as a guide for functional adjustments.
Personnel who have access to these adjustments should be familiar with the equipment
manufacturer’s instructions and the machinery used with the electrical equipment.
Only those operational adjustments actually required by the operator should be accessible to the
operator. Access to other controls should be restricted to prevent unauthorized changes in
operating characteristics.
WARNING
UNEXPECTED EQUIPMENT OPERATION
 Only use software tools approved by Schneider Electric for use with this equipment.
 Update your application program every time you change the physical hardware
configuration.
damage.
Intention
This document is intended to provide a quick introduction to the described system. It is not
intended to replace any specific product documentation, nor any of your own design
documentation. On the contrary, it offers information additional to the product documentation on
installation, configuration and implementing the system.
The architecture described in this document is not a specific product in the normal commercial
sense. It describes an example of how Schneider Electric and third-party components may be
integrated to fulfill an industrial application.
A detailed functional description or the specifications for a specific user application is not part of
this document. Nevertheless, the document outlines some typical applications where the system
might be implemented.

The architecture described in this document has been fully tested in our laboratories using all the
specific references you will find in the component list near the end of this document. Of course,
your specific application requirements may be different and will require additional and/or different
components. In this case, you will have to adapt the information provided in this document to
your particular needs. To do so, you will need to consult the specific product documentation of the
components that you are substituting in this architecture. Pay particular attention in conforming to
any safety information, different electrical requirements and normative standards that would apply
to your adaptation.
It should be noted that there are some major components in the architecture described in this
document that cannot be substituted without completely invalidating the architecture,
descriptions, instructions, wiring diagrams and compatibility between the various software and
hardware components specified herein. You must be aware of the consequences of component
substitution in the architecture described in this document as substitutions may impair the
compatibility and interoperability of software and hardware.
CAUTION
EQUIPMENT INCOMPATIBILITY OR INOPERABLE EQUIPMENT
Read and thoroughly understand all hardware and software documentation before attempting
any component substitutions.

This document is intended to demonstrate the control part of a high availability system using a
redundant M580 ePAC.
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.

The TVDA collection
Tested Validated Documented Architecture (TVDA) guides are meant to help in the
implementation of specified solutions. TVDA guides provide a tested and validated example of
the proposed architecture to help project engineers and Alliance system integrators during the
design and implementation of a project. The TVDA helps users analyze their architectures,
confirm the feasibility of their systems, and speed up system implementation.
Each TVDA provides users with:
 A reference architecture based on Schneider Electric’s PlantStruxure solution
 Documentation of the system requirements of the architecture – response times, number of

devices, features
 Design choices for the application – software and hardware architectures
 Test results to confirm the requirements are met
All explanations and applications have been developed by both Schneider Electric experts and
system integrators in our PlantStruxure labs.
TVDAs are not intended to be used as substitutes for the technical documentation related to the
individual components, but rather to complement those materials.
Development environment
Each TVDA or STN has been developed in one of our solution platform labs using a typical
PlantStruxure architecture.
PlantStruxure, the process automation system from Schneider Electric, is a collaborative

architecture that allows industrial and infrastructure companies to meet their automation needs
while at the same time addressing their growing energy efficiency requirements. In a single
environment, measured energy and process data can be analyzed to yield a holistically optimized
plant.
Video player requirements

This document includes video content. The following recommendations must be observed to view
the videos:
 Adobe® Flash® Player 11 plug-in or higher must be installed in your computer
 The recommended minimum screen resolution is 1280x800

Version History
Version Date Description
V1 6/2016 Creation of the document
V2 6/2017 Update architecture and adding extra features.
10

Table of contents
1. Introduction 13
1.1. Purpose 13
1.2. Customer Challenges 13
1.3. Prerequisites 14
1.4. About this Document 14
1.5. Glossary 15
2. Selection 17
2.1. PlantStruxure Modular Architecture 17
2.2. Modicon M580 Redundant System Components 17
2.3. SCADA Redundancy 25
2.4. DTM 26
2.5. Selected Architecture 28
2.6. Software 30
3. Design 31
3.1. M580 Redundant System 31
3.2. Network Design 46
3.3. Wonderware System Platform 51
3.4. System Tools 54
3.5. Project Flow 56
4. Configuration 57
4.1. PAC Configuration 57
4.2. Field Device Configuration 81
4.3. Ethernet Network Configuration 89
4.4. Wonderware System Platform Configuration 99
4.5. OFS Configuration 99
5. Implementation 101
5.1. Redundant PAC Management 101
5.2. Redundant Power Supplies 104
5.3. BMENOC0321 IP Forwarding Management 105
5.4. Modbus Network 106
11

6. Operation and Maintenance 109
6.1. System Identification 109
6.2. System Commissioning 110
6.3. System Operation 116
6.4. System Maintenance 124
7. Validation 133
7.1. Functional Tests 133
7.2. Switchover Impact on System Components 137
7.3. Performance Tests 139
8. Conclusion 147
9. Appendix 149
9.1. Glossary 149
9.2. Bill of Material and Software 151
9.3. Reference Documents 154
9.4. Project Flow Steps 155
12

OOOOOOO 1 – Introduction
1. Introduction
PlantStruxure is an automation system from Schneider Electric designed to address the key
challenges faced by many different types of users, including plant managers, operations
managers, engineers, maintenance teams, and operators, by delivering a system that is scalable,
flexible, integrated, and collaborative.
This document presents one of the PlantStruxure features, using Ethernet as the backbone
around the Modicon M580 redundant offer. This TVDA describes how to implement a high
availability architecture using an M580 redundant system combined with redundant Wonderware
System Platform (WSP) at the SCADA level.
1.1. Purpose
The purpose of this TVDA is to provide the guidelines, examples, and procedures to implement a
high availability automation system using PlantStruxure. This TVDA will focus on the PAC level,
while another dedicated TVDA is available for the SCADA part.
We will demonstrate how to use theoretical methods to calculate system performance. The
validation process will include some performance tests to validate the real results against the
theoretical values.
1.2. Customer Challenges

In some applications and industrial regulations, a process operation is required to run 24/7. An
interruption can impact different processes or operations that are dependent on that particular
part of the system. In many cases, such an interruption can lead to significant product damage,
scrap, spoilage, or waste, with corresponding financial losses.
Recovery from a process interruption varies from one industry to another. In some cases, the cost
of the time, effort, repair, recovery, and restarting due to an unexpected production stoppage is
unacceptable. In some forced shutdown cases, it can actually be more economical to replace
parts of the production equipment than to repair them, as in the case of some furnaces, for
instance.
When this is the case, the main challenges are:
 High performance and fast response
 Building control systems that provide high levels of availability and reliability
 Easier diagnostics, remote access, transparency, and maintainability
13

 Modification without process interruption
 Scalable system
1.3. Prerequisites
We recommend readers have a good knowledge of the following:
 Unity Pro
 Wonderware System Platform (WSP)
 ConneXium switches and networking
1.4. About this Document

This document will present a redundant and modular architecture. The proposed architecture is
based on mixed DIO (Distributed Inputs Outputs) and RIO (Remote Inputs Outputs).
This document will start by presenting the system, including all the elements. This will cover the
features provided by the M580 redundant system. In addition, it will provide a brief description of
the redundant operation and modes. Based on that, we will define our architecture and select the
right components.
In the Design chapter, based on the selected architecture, we will go into a detailed design of the
architecture. That will include the network design, which encompasses the network devices, IP
addressing, subnets, and routing. The operating modes, conditions, and the libraries to be used
will also be addressed in this chapter.
The Configuration chapter will show how to configure the various system components. In this
chapter, we will do the PAC and DTM configuration in Unity Pro, network configuration, and the
WSP project configuration.
Implementation will be done using the provided libraries and functions to complete the final
customization to address the project requirements.
The Operation and Maintenance chapter will provide useful recommendations about how to
operate and diagnose the system.
The Validation chapter will show performance test results and compare them to the project
requirements and theoretical calculations. We will also initiate some events to test the system’s
response and reaction.
14

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

16

OOOOOO 2 – Selection
2. Selection
2.1. PlantStruxure Modular Architecture

A modular architecture is one of the PlantStruxure reference architectures. The aim of the
modular reference architecture is to propose a decentralized control system with multiple PACs
and a distributed SCADA system. Each PAC is dedicated to managing one or several functional
units.
All the functional units and the control room are connected to an Ethernet network. A layered
Ethernet network topology is used between the control room and the functional units. A separate
Ethernet control room network isolates the different communication traffic.
This TVDA focuses on the M580 modular and redundant architecture, using Ethernet as the
system backbone. The Modicon M580 ePAC (Ethernet Programmable Automation Controller)
offers openness, flexibility, robustness, and sustainability. It is designed with an Ethernet
backbone to optimize connectivity and communications. It supports X80 common I/O modules,
which can be easily integrated into its architecture. The powerful processors offer high levels of
computation for complex networked communication, display, and control applications.
2.2. Modicon M580 Redundant System Components

A simple redundant system includes, at minimum, two redundant local racks configured with
identical hardware and software. The main rack can host only communication modules and
embedded switching modules, in addition to the processors, of course. I/O modules are not
supported in the local rack, but they can be added to the RIO drops and distributed equipment.
Note: The minimum configuration for a Modicon M580 redundant system is two racks, each
equipped with a power supply and a processor. The minimum configuration provides full
redundant operation, with connection to the RIO ring. All other modules provide extra
functionality, but are not mandatory for the redundant operation or RIO drops connection.
The system may also include RIO drops located on the main Ethernet RIO ring and/or distributed
equipment not residing directly on the RIO ring.
RIO drops provide deterministic communication response times on the main Ethernet RIO ring
and the sub-rings so that a RIO modules update is synchronized with CPU tasks and participate
to the redundancy state of the CPU; whereas distributed equipment response time is not
deterministic.
17

In a redundant system, you can install only one main ring which connects to the Ethernet
backplanes of the redundant CPUs. If DIO rings are connected through NOC modules, the
Ethernet backplane port of the NOCs has to be disabled.
2.2.1. Local racks
The local rack contains the CPU, a power supply, and communication modules (DIO scanners or
Ethernet switch modules). The type and quantity of communication modules depend on the
selected CPU reference.
Racks
Each local rack in an M580 redundant system – both primary and standby – consists of a single
rack. Extensions to the local rack are not permitted in a redundant system. Both Ethernet-based
(BME XBP*) and legacy X-Bus (BMX XBP*) racks are supported in the local racks, however, the
legacy X-Bus racks do not provide Ethernet transparency.
Your choice of rack determines the available power supply, which can be either standalone or
redundant.
Power supply
As noted above, the choice of possible power supply depends on the choice of the rack.
Redundant power supplies require specific racks (BME XBP *02) with two redundant power
supply slots.
CPU
The redundant processor is dedicated for the redundant architecture that physically occupies two
module slots on a backplane. The redundant processors have different memory sizes, processing
speeds, maximum number of RIO drops, and embedded Ethernet functions.
18

Table 1: M580 redundant processors capacity
The redundant CPU modules have the same external hardware features, as shown in the
following figure.
19

Figure 1: M580 redundant CPU external hardware
Redundancy link SFP transceivers
Besides the main RIO ring connecting both redundant CPUs, a dedicated redundancy link has to
be connected between the two processors. Each M580 redundant CPU is fitted with an SFP
socket that supports a copper or fiber-optic SFP transceiver. The available SFP transceiver
modules include two types based on the distance between the two racks. One SFP with RJ45
copper connection is available for distances up to 100m, and the other, with a single-mode fiber-
optic connection, is available for distances up to 15 km.
20

2.2.2. Network components
Ethernet switch module
Thanks to the Ethernet backbone at the heart of

the system, an Ethernet switch module can be
plugged directly into the Ethernet backplane,
with no additional cables required. The
BMENOS0300 Ethernet switch module
eliminates the need for an external switch or
external power supply wiring. A BMENOS0300
Ethernet switch module can be used to connect
RIO and DIO sub-rings, as well as DIO clouds, Figure 2: Ethernet switch module NOS
to the main RIO ring.
The BMENOS0300 module is used for these purposes:
 Reduce system costs by using a BMENOS0300 module instead of a dual-ring switch (DRS)
to connect RIO and DIO sub-rings to the Ethernet I/O network, and instead of a
BMENOC03•1 to connect distributed equipment to the network
 Enable RSTP recovery support for the devices on RIO and DIO sub-rings
 Isolate the RIO and DIO sub-rings.
ConneXium Ethernet switches
In our architecture, you can use different Ethernet switch types from Schneider Electric’s
ConneXium Ethernet product line. However, for our architecture, we will use the ConneXium
switches with gigabit ports in the main control ring to create one gigabit speed ring.
21

The following switch should be used: TCSESM103F23G0 (10 copper
cable ports, including two gigabit ports).
The switches that we need in our system use only copper cable
connections. Other switch models with fiber-optic ports can be used, if
needed for different systems.
Figure 3: TCSESM103F23G0
BMENOC0321 IP forwarding module
The BMENOC0321 module is an in-rack module with an IP forwarding service that can eliminate
the need for an external router in many cases, potentially reducing the system’s cost and
footprint. The NOC0321 module supports network routing for up to three different IP subnets,
thus separating the architecture into three different broadcast domains. This is suitable for
architectures where each area of the plant needs to be isolated with full transparency, and where
significant traffic is anticipated. The Ethernet traffic between the NOC321 and CPU flows through
the Ethernet backplane, not the X-Bus.
However, the L3 switches – routers – are required for bigger architectures where there are more
than three subnets. Also, when using peer-to-peer communication, an external router is required
because the system needs more static routes or dynamic routing, which cannot be configured on
the NOC0321.
The NOC0321 module dual-ring ports have a one-gigabit speed, so we can create a backbone
control ring with a speed of one gigabit.
2.2.3. Ethernet RIO Drops
A RIO drop is connected to an Ethernet RIO ring or RIO sub-ring. Each drop consists of one or
two racks, including (e)X80 I/O modules and/or other supported modules. A RIO drop is
connected to the daisy-chain ring on which the Ethernet RIO network resides. Each remote drop
contains one BM•CRA312•0 (e)X80 Ethernet I/O (EIO) adapter module.
Remote eX80 EIO adapter modules are available in Ethernet (BME) and X Bus (BMX) versions. If
you plan to use X80 modules that require Ethernet, then choose a BME-style X80 EIO adapter
module. If your X80 modules use only X-Bus for backplane communication, then you can use a
BMX-style X80 EIO adapter module or a BME-style X80 EIO adapter module.
In our architecture, RIO drops are connected to the main ring via copper cable to the CPU on the
local rack. The maximum number of drops supported in an M580 network is 31, depending on the
selected CPU.
22

3
Figure 4: Simple M580 redundant RIO main ring architecture
2.2.4. Distributed devices
In an M580 system, distributed equipment can either communicate with an M580 Ethernet RIO
network, or it can be isolated from the RIO network:
1. Integrating distributed equipment into the Ethernet RIO network
Distributed equipment is connected to the RIO main ring through the service port of a CPU,
an Ethernet communication module, or an X80-EIO adapter module on the main ring or sub-
ring. However this type of connection provides one link to the DIO devices.
Ethernet switches are still an option to connect the DIO cloud to the Ethernet RIO network.
There are two different types of switches that can be used for that purpose, either the
ConneXium DRS switches or the X80 Ethernet switch module BMENOS0300.
The DRS switches can be connected directly to the main Ethernet RIO ring, allowing
connection to a DIO cloud or sub-ring.
23

Figure 5: DIO sub-ring connected to an Ethernet RIO network using DRS switch
The BMENOS0300 is an X80 Ethernet switch module that can be inserted in the Ethernet
RIO drops, also allowing connection to a DIO cloud or sub-ring.
Figure 6: Replacing a DRS switch with a BMENOS0300 module in a RIO drop
However, no DIO devices are allowed to be connected directly to the main RIO ring.
2. Isolating distributed equipment from an Ethernet RIO network
Away from the Ethernet RIO network, distributed equipment in DIO networks can be
managed by a BMENOC03•1 module whose Ethernet backplane connection is disabled. The
backplane port has to be disabled to isolate the DIO network from the RIO network.
24

Figure 7: Ethernet DIO ring isolated from the Ethernet RIO network
These DIO networks may contain devices such as TeSys T, motor drives, Modicon STB
devices, HMI, iPMCC, and PCs. If you use a device that has two Ethernet ports and supports
RSTP, you can connect the device in an RSTP ring. In this architecture, the distributed
devices are isolated from the Ethernet RIO network as there is no common network path
between the RIO and DIO networks.
2.3. SCADA Redundancy

Several topologies and protocols are used to increase the availability of the networks. The main
idea is to create alternative paths to access devices, so in the event that a network element on
one path stops functioning, another path can be used.
Ring topologies are mainly used to increase the level of network availability. Network redundancy
management protocols, such as Rapid Spanning Tree Protocol (RSTP) or Media Redundancy
Protocol (MRP), are used for network recovery.
Our project features three sub-networks:
 A supervisory network linking all the computers of the galaxy (plant information network)
 A control network linking PACs and WSP’s Automation Object Servers (control network)
 A device network linking PACs and remote Ethernet I/O modules (device network)
The supervisory network that connects the WSP galaxy computers is addressed in a separate
TVDA focusing on high availability architectures with WSP. Therefore, we will not focus on the
SCADA part in this TVDA. The control network is the network part which connects our M580
redundant system with Wonderware System Platform.
In terms of network, and depending on the system’s availability requirements, we can select a
single or a dual redundant control network. In our architecture, we will select the single ring
control network.
25

2.4. DTM
The PlantStruxure architecture complies with the FDT standard and provides some adaptations to
facilitate system configuration, including the fieldbus configuration. The PlantStruxure architecture
uses five DTM categories, combining DTM types and their functions:
 Comm DTMs are either pure communication DTMs when connected to Ethernet devices, or
support a gateway function to allow a remote connection to another fieldbus (e.g. Modbus
Serial Line, CANopen, Profibus, and so on). In the PlantStruxure context, a comm DTM can
combine the communication and gateway functions of standard DTMs.
 Master DTMs include a fieldbus configuration and management function using the FDT
technology and an optional remote master device configuration and management function. A
fieldbus master DTM (e.g. Eth Master DTM or Profibus Master DTM) combines the
communication, gateway, and fieldbus configuration functions. When it is used, the fieldbus
master DTM is the first DTM activated from an FDT frame. The fieldbus master DTMs use
PlantStruxure-specific interfaces to be integrated in Unity Pro – they cannot be used in other
environments.
 Gateway DTMs are used to transition between different communication paths responsible
for the inter-protocol mapping (for instance, between Ethernet Modbus TCP and Modbus
Serial Line).
 Device DTMs are specific DTM software programs that provide device level services (e.g.
ATV or TeSys), or they can be the DTM interface associated to a non-DTM device tool, such
as Advantys Configuration Software.
 Generic DTMs are generated from a device description file (e.g. DDXML files or EDS files
for CANopen) and provide generic services.
The following figure illustrates the previous description:
26

Frame Ethernet
Application
1
Ethernet Master DTM (1)
Ethernet
2
STB DTM (2)
3
ATV DTM (3)
4
MB SL Comm DTM (4)
Modbus SL
5
ATS DTM (5)
Figure 8: DTM tree example in a PlantStruxure architecture
27

2.5. Selected Architecture
Figure 9: M580 redundant architecture
Control network
Two redundant SCADA servers and one engineering workstation are connected to the control
network. Both SCADA servers contain WSP application servers and have OFS installed. Each
server has three network interfaces, one for the control network, one for the redundancy link, and
one interface for the galaxy connection.
The control network is a single ring connected between two extended ConneXium extended
switches and all the NOC0321 modules. With the extended ConneXium switches and the
NOC321 modules, the control ring has a speed of one Gigabit. All the NOC0321 modules are
installed on the PAC’s local racks.
A separate workstation is connected to the ring to act as the time server for the whole system.
28

M580 system
The selected topology features two M580 redundant systems in two different control units.
Control unit one has one RIO ring with a DIO sub-ring and one isolated DIO ring. In that design,
the CPU scans the main RIO ring and the DIO sub-ring while the NOC module scans the other
DIO ring. The NOC module backplane port is disabled to isolate the DIO network from the RIO
network. In this case, the NOC module is connected to the NOC0321 module through an external
link between the service ports of both modules. The purpose of this link is to provide transparency
between the DIO network and the control network.
The selected processor for this control unit is the PMEH584040 which supports up to 16 RIO
drops. The NOC module, which is the DIO scanner in this case, is the BMENOC0301 that
supports up to 128 DIO devices. The BMENOC321 module is installed in the main rack to provide
routing functionality between the different subnets.
A BMXNOM0200 is installed in a RIO drop. This NOM module has two Modbus serial ports to
connect Modbus serial DIOs. On these two ports, a power meter, variable speed drive, and motor
starter are connected. These DIOs are scanned by the CPU.
A BMENOS0300 switch module is installed on one of the drops, connecting two Altivar Process
drives to the RIO network. Both drives are daisy chained in an RSTP ring with the NOS module.
The first ERIO rack has two redundant power supplies installed.
Control unit two has only a DIO ring connected through a BMENOS0300 switch module, and all
the DIOs are scanned by the CPU. The BMENOC321 is used to route between the field devices
and the control network. The selected processor for this control unit is the PMEH582040 which is
more suitable to smaller systems than the PMEH584040.
Wireless access
A PMXNOW0300 WiFi module is installed on one of the X80 drops to provide wireless access to
the system. The WiFi module is connected to the system through an interlink with the service port
of the CRA module where it is installed.
Subnetting and routing
In order to provide transparency and network isolation at the same time, three different subnets
are used in this architecture. Routing between the three subnets is managed by the NOC0321
module that is installed on the local rack.
Note: The M580 CPU supports up to 64 DIO, three of them are reserved for local slaves and 61
are available for DIO scanning. The NOC module supports up to 128 DIO, 16 of them are
reserved for local slaves and 112 are available for DIO scanning.
29

Note: “Local Slave” is a functionality offered by Schneider Electric EtherNet/IP communication
modules that allows a scanner to take the role of an adapter. The local slave enables the module
to publish data via implicit messaging connections. Local slave is typically used in peer-to-peer
exchanges between PACs
2.6. Software
This section describes the software selected for this project. For detailed information about the
hardware and software requirements, please refer to the specific product manuals. The versions
used for this document are listed in the Appendix chapter.
Unity Pro XL is used to program the M580 PAC.
Advantys Configuration Software is used, in addition to Unity Pro, to configure the

Modicon STB islands.
Schneider Electric's OPC Factory Server (OFS) software is used to connect

Wonderware System Platform to the M580 HSBY PAC.
The Wonderware Application Server is designed to leverage existing Wonderware

products such as InTouch for visualization, Wonderware Historian, and the device
integration product line (I/O servers) for device communications. The Wonderware
Application Server uses InTouch for visualization, with the addition of platforms to the
visualization node.
30

OOOOO 3 – Design
3. Design
In this chapter we will go through the design details of our selected architecture. This will cover
the following topics:
 The M580 redundant system definition, principles, and modes
 Network design, routing, and IP addressing
 Library components and Unity Pro DDT that are going to be used in the application
 System performance and ART calculations guidance
3.1. M580 Redundant System
3.1.1. Principle
In the M580 redundant system, two PACs are configured with identical hardware and software.
One of the PACs acts as the primary, which runs the application by executing program logic and
operating RIO drops and distributed equipment. The other PAC acts as standby. The primary
PAC updates the standby PAC at the beginning of each scan cycle. The standby is ready to
assume control within one scan cycle if the primary stops communications.
The primary and standby states are interchangeable. When the system starts, one of the PACs
becomes the primary, the other one enters in standby or wait mode. There is no predefined order.
The RIO and DIO networks are operated by the primary PAC.
The system continuously monitors itself. If a triggering event occurs, the redundant system
switches control to the standby, which then becomes the primary PAC. If the standby PAC stops
communications, the primary continues to operate without a backup.
When you configure the Main IP Address of a redundant system, the primary PAC uses the
assigned IP address, while the standby PAC automatically uses the assigned IP address +1.
3.1.2. Redundancy system states
There are two states for the M580 redundant PAC: operating state and system state. The
operating state is the operational status of the CPU, similar to the standalone M580 system state.
While the redundant system state is the CPU status concerning the redundancy operation. The
following table shows the states supported by the CPU in a redundant system.
31

Table 2: M580 redundant system states
This list describes the redundancy states:
3. Primary: The PAC controls all system processes and devices:
 It executes program logic
 It receives input from, and controls output to, distributed equipment and RIO drops
 If connected to a PAC in standby state, the primary PAC checks the status of, and
exchanges data with, the standby PAC
In a redundant network, both PACs can be primary if both the redundancy and Ethernet RIO
links are not functioning. When either of these two links is restored, the PAC does one of the
following:
 Remains in the primary state
 Transitions to the standby state
 Transitions to the wait state
4. Standby: The standby PAC maintains a state of readiness. It can take control of system
processes and devices if the primary PAC cannot continue to perform these functions:
 It reads the data and the I/O states from the primary PAC
 It does not scan distributed equipment, but receives this information from the primary
PAC
 It executes program logic. You can configure the standby PAC to execute:
i. The first section of program logic (the default setting)
ii. Specified sections of program logic, including all MAST and FAST task sections.
This can be specified in the Condition tab in the Properties dialog for each section
 On each scan, it checks the status of the primary PAC
5. Wait: The PAC is in RUN mode, but cannot act as either primary or standby. The PAC
transitions from the wait state to either the primary or standby state, when all preconditions
for that state exist, including:
32

 The state of the redundancy link
 The state of the Ethernet RIO link
 The presence of at least one connection with an Ethernet RIO drop
 The position of the A/B rotary selection switch on the rear of the CPU
 The state of the configuration
In the wait state, the PAC continues to communicate with other modules on the local rack, and
can execute program logic, if configured to do so.
6. INIT: Both the PAC and the redundant system are initializing
7. Stop: The PAC is in STOP mode. On the STOP to RUN transition, the PAC may move to the
wait, standby, or primary state. This transition depends on the state of the Ethernet RIO and
redundancy links, and on the position of the A/B rotary selection switch on the rear of the
CPU.
3.1.3. PAC functions for redundancy system states
Each PAC in the redundant system performs different functions, depending on its state. This table
summarizes the different functions/rules for each PAC, based on its redundancy state:
Table 3: PAC functions in a redundant system
3.1.4. Switchover
The purpose of a redundant system is to be ready to perform a switchover, if needed. A

switchover is the immediate transfer of control of the system from the primary PAC to the standby
PAC. The switchover needs to be bumpless.
33

The M580 redundant system continuously monitors ongoing system operations, and determines if
a condition requiring a switchover exists. On each scan, both the primary PAC and the standby
PAC check the health of the system.
The primary PAC checks the health of the following:
 The Ethernet RIO network link
 The redundancy link between the primary and standby CPUs
The standby PAC checks the following:
 Primary PAC health
 Identity of modules in both the primary and standby racks
 Application versions running in the primary and standby CPUs
 Firmware versions of the primary and standby CPUs
 Health of the redundancy link between the primary and standby CPUs
Before each MAST task, the primary PAC transfers status and I/O data, including date and time
data, to the standby PAC system. On switchover, the standby PAC applies this time data and
continues the same time stamping sequence. The maximum amount of transferable redundancy
data depends on the CPU.
Note: Both the primary PAC and the standby PAC maintain independent event logs. If a
switchover occurs, the events recorded in the log of the former primary PAC will not be included
in the event log of the new primary (formerly the standby) PAC.
Switchover causes
Switchover occurs automatically, without any user or logic interference, if one of the following
events occurs:
 The primary PAC has encountered a blocking condition and entered the HALT state.
The HALT state means that the CPU has an application, but it has stopped operating
because it has encountered an unexpected blocking condition which puts the CPU in a HALT
state, resulting in either a recoverable or non-recoverable condition
 The primary PAC has detected an unrecoverable hardware or system error
 The primary PAC has received a STOP command from Unity Pro or the DDDT
 An application program is being transferred to the primary CPU
 Primary PAC power is turned off
 The following events occur simultaneously:
34

 The primary PAC loses communication to all RIO drops
 The redundancy link is healthy
 The standby PAC maintains communication with at least one RIO drop
 The DDDT CMD_SWAP command is executed by either program logic or an animation table
Force command
CAUTION
RISK OF UNINTENDED OPERATION
Before you execute a switchover (either by application logic or the Unity Pro GUI), confirm that
the standby PAC is ready to take the primary role by verifying the status in the dedicated DDDT.
 Clicking the HSBY Swap button in the Task tab of the CPU Animation window in Unity Pro
Some conditions do not cause automatic switchover. User logic can force the switchover
occurrence, if needed. The following are some examples of these conditions:
 Simultaneous interruption of communication with all RIO drops by both the primary and
the standby PACs
 Partial interruption of communication with the RIO drops by the primary PAC
 Overloaded broadcast traffic generated by a peer (for example, SCADA or another PAC)
 A BMENOC03•1 module stops operating
 Removal of an SD memory card
Switchover execution time
If both the primary PAC and standby PAC are operating normally, the redundant system detects a
switchover causal event within 15 ms. The time to complete a switchover can vary from the
maximum detection time of 15 ms, up to one MAST cycle.
After the switchover, the former standby PAC becomes the primary. In the worst case scenario,
the new primary PAC operates with the data of scan cycle N, while the outputs have received the
data of scan cycle N+1 (from the former primary PAC). The new primary PAC re-evaluates
outputs beginning with scan N+1.
Because the redundancy switchover evaluation occurs during the MAST task, some FAST task
program execution may be skipped for this scan cycle.
35

Switchover effects on the system
For more details about the switchover effects on all the system components, refer to the M580
redundant user guide. However, the following points summarize the effects on some system
parameters and components:
 The main IP address setting is automatically transferred from the former primary CPU to the
former standby – now the new primary – CPU. Similarly, on switchover, the main IP address
+ 1 setting is automatically transferred from the former standby CPU to the new standby.
 For RIO drops, the switchover is bumpless: the state of outputs is not affected by the
switchover. During redundant operations, each PAC maintains an independent, redundant
owner connection with each RIO drop. Each PAC makes this connection via IP address A or
IP address B, depending on the A/B/Clear rotary switch selection for each CPU. When a
switchover occurs, the new primary PAC continues to communicate with I/O via its pre-
existing redundant owner connection.
 The behavior of distributed equipment outputs during a switchover depends on whether the
equipment supports hold-up time. If the device does not support hold-up time, its outputs will
most likely go to fallback when the connection with the primary PAC is interrupted, and will
recover their state after reconnecting with the new primary PAC.
To achieve bumpless behavior, the outputs need to support a sufficiently long hold-up time.
The hold-up time represents the time that device outputs are maintained in their current
states after a communication disruption and before taking their fallback values. Because
distributed devices are not connected to the primary CPU during a switchover, set the hold-
up time to a value greater than the expected duration of the communication interruption.
For Modbus TCP devices, the hold-up time should be higher than (4.4 x (MAST period) +
600 ms).
For EtherNet/IP devices, set the hold-up time to exceed (4.4 x (MAST period) + 5000 ms).
Recovery of the former primary PAC
The former primary PAC may or may not become the standby PAC, depending on the cause of
the switchover.
3.1.5. Data exchange in a redundant system
The different types of data that are being exchanged between the two PACs in a redundant
system are summarized in the following points.
Periodic data exchanges
The redundant CPUs perform two periodic data exchanges:
36

 Before each MAST cycle, the primary CPU transmits to the standby CPU application
variables, system status, and I/O data.
 Periodically, both CPUs exchange the content of the T_M_ECPU_HSBY DDT (this is
explained in detail further on).
Data transmitted during each MAST cycle
Before each MAST task, the primary CPU transmits data to the standby CPU in two ways. The
primary CPU uses:
 The redundancy link to send application variables, system status, and I/O data
 The Ethernet RIO link to send application variables and system status
When communication is lost on the redundancy link, the standby CPU does not receive updated
I/O data and application variables. If communication is lost for three seconds or more, the
standby CPU enters wait state.
Note: Due to I/O data size and transfer time constraints, I/O data is not exchanged between the
primary CPU and the standby CPU over the Ethernet RIO link.
Transfer of the Hot Standby DDT
This is a dedicated set of variables that can be used to exchange specific data between both
PACs. This is a two-way data exchange made while both CPUs are running. This exchange is
made over both the redundancy link and the Ethernet RIO link.
The exchange occurs every 5 ms over the redundancy link, and every 10 ms over the RIO link. It
occurs regardless of the redundancy state of the CPUs (primary, standby, wait, or stop). This
exchange includes up to 64 words of variable items.
Associating variables with tasks
Each data item is associated with a task. When you create a new data item in the Data Editor,
you need to associate it with a task:
 A MAST task is required by the redundant system, and can be assigned to data items related
to the redundant CPU and RIO drops (both Quantum and M580).
 FAST tasks are optional for all redundant CPUs, and can be assigned only to M580 (e)X80
drops.
37

3.1.6. Hot Standby DDT
By default, in an M580 redundant application, a special DDT is created automatically by Unity

Pro, named T_M_ECPU_HSBY. This DDT is the exclusive interface between the M580
redundant system and the application running in a redundant CPU.
The T_M_ECPU_HSBY DDT presents three distinct sections:
 LOCAL_HSBY_STS: Provides information about the local PAC. Data is both auto-generated
by the redundant system, and provided by the application. This data is exchanged with the
remote PAC.
 REMOTE_HSBY_STS: Provides information about the remote PAC, and contains the image
of the last received exchange from the counterpart PAC. The validity of this information is
represented by the REMOTE_STS_VALID flag in the common part of this DDT.
 A common part of the DDT: Consists of several objects, including status data, system control
objects, and command objects:
 Status data is provided by the redundant system as a result of diagnostic checking
 System control objects enable you to define and control system behavior
 Command data objects include executable commands you can use to modify the system
state
Note: In the DDT, Local refers to the redundant PAC to which your PC is connected, while
Remote refers to the other redundant PAC.
The following table shows the structure of this DDT:
Element Type Description Written By
 True: Both HSBY_LINK_ERROR and

HSBY_SUPPLEMENTARY_LINK_ERROR
are set to 0.
REMOTE_STS_VALID BOOL System
 False: Both HSBY_LINK_ERROR and
HSBY_SUPPLEMENTARY_LINK_ERROR
are set to 1.
The original applications in the two PACs are

APP_MISMATCH BOOL System
different.
 True: The standby remains standby in case

LOGIC_MISMATCH_ of logic mismatch.
BOOL Application
ALLOWED  False: The standby goes into wait state in
case of logic mismatch.
38

Different revisions of the same application exist

LOGIC_MISMATCH BOOL System
in the two PACs.
 True: The applications in the primary PAC

and the standby PAC are different in at
least one SFC section. In the event of a
SFC_MISMATCH BOOL switchover, the graphs that are different are System
reset to their initial state.
 False (default): All SFC sections are

identical.
The two PACs are running different revisions of

the same application. in this condition:
OFFLINE_BUILD_  A data exchange between the two PACs

BOOL System
MISMATCH may not be possible
 A swap or switchover may not be bumpless
 Neither PAC can be standby
The number of build change differences

between the applications in the primary PAC
APP_BUILDCHANGE_DIFF UINT System
versus the standby PAC. Evaluated by the
primary.
Maximum number of build change differences

MAX_APP_ permitted by the redundant system, from 0...50
UINT Application
BUILDCHANGE_DIFF (default = 20). Set in the Hot Standby tab as
Number of modifications.
Allows mismatched firmware between primary

and standby CPUs:
 True: The standby remains standby in case

FW_MISMATCH_ALLOWED BOOL Application
of FW mismatch
 False (default): The standby goes into wait

state in case of FW mismatch
FW_MISMATCH BOOL The OS are different in the two PACs. System
DATA_LAYOUT_ The data layouts are different on the two PACs.

BOOL System
MISMATCH The data transfer is partially performed.
39

Number of KB sent by the primary and

discarded by the standby (rounded up to the
DATA_DISCARDED UINT System
next KB). Represents data for variables added
to primary, but not to standby.
Number of KB not updated by the standby

(rounded up to the next KB). Represents
DATA_NOT_UPDATED UINT System
variables deleted from the primary that remain in
the standby.
 False: The backup applications in both

redundant PACs are equal
NOTE: The backup application resides in

flash memory or on the SD memory card of
BACKUP_APP_MISMATCH BOOL the PAC. It is created either by the PLC → System
Project Backup.. → Backup Save
command, or by setting the %S66 system
bit (Application Backup) to 1.
 True: All other cases
PAC A is configured to enter the primary or

PLCA_ONLINE BOOL standby state. Configuration
NOTE: Executable only on PAC A.
PAC B is configured to enter the primary or

PLCB_ONLINE BOOL standby state. Configuration
NOTE: Executable only on PAC B.
 Set to 1 by program logic or animation table

to initiate a switchover. The primary goes
into wait, then the standby goes primary,
finally the wait goes standby. The command
is ignored if there is no standby. Application /
CMD_SWAP BOOL
System
NOTE: Executable on both primary and
standby.
 Reset to 0 by the system on switchover

completion or if there is no standby.
40


to start an application transfer from the
primary to the standby. Executable only on
the primary.
Application /
CMD_APP_TRANSFER BOOL NOTE: The application transferred is the
System
backup application, stored in flash memory
or on the SD card.
 Reset to 0 by the system on transfer

completion.

to automatically start in Run after a transfer.
NOTE: Executable only on the primary.
CMD_RUN_AFTER_  Reset to 0 by the system after transfer Application /

BOOL[0..2]
TRANSFER completion and: System
 Remote PAC is in Run
 PAC is not primary
 By animation table or logic command

to run the remote PAC. This command is
ignored if the CMD_STOP_REMOTE is
true. Application /
CMD_RUN_REMOTE BOOL
System
NOTE: Executable only on the primary.
 Reset to 0 by the system when the remote

PAC enters standby or wait state.

to stop the remote PAC.
NOTE: Executable on the primary, the

CMD_STOP_REMOTE BOOL Application
standby, or a stopped PAC.
 Reset to 0 by the application to end the stop

command.
41


to begin a comparison of the initial values of
variables exchanged by the two redundant
PACs.
CMD_COMPARE_INITIAL_ Application /
BOOL NOTE: Executable on both primary and
VALUE System
standby only in Run mode.
 Reset to 0 by the system when the

comparison is complete, or if the
comparison is not possible.
 True: If the initial values for exchanged

variables are different or if the comparison
INITIAL_VALUE_
BOOL is not possible. System
MISMATCH
 False: If the initial values for exchanged
variables are identical.
 True: If the exchanged data from the

previous MAST cycle was received by the
standby.
MAST_SYNCHRONIZED BOOL System
 False (default): If the exchanged data from
at least the previous MAST cycle was not
received by the standby.
 True: If the exchanged data from the

previous FAST cycle was received by the
standby.
FAST_SYNCHRONIZED BOOL System
 False (default): If the exchanged data from
at least the previous FAST cycle was not
received by the standby.
T_M_EDPU_
LOCAL_HSBY_STS Redundancy status for the local PAC
HSBY_STS
T_M_EDPU_
REMOTE_HSBY_STS Redundancy status for the remote PAC
HSBY_STS
Table 4: M580 Hot Standby DDT structure
42

The last two variables in the HSBY DDT LOCAL_HSBY_STS and REMOTE_HSBY_STS have a
dedicated data type named T_M_ECPU_HSBY_STS. The following table shows the structure of
this DDT:
 True: No connection on the redundancy
HSBY_LINK_ERROR BOOL link. System

 False: The redundancy link is operational.
HSBY_  True: No connection on the Ethernet RIO
SUPPLEMENTARY_ BOOL link. System
LINK_ERROR  False: The Ethernet RIO link is operational.
 True: The PAC is in Run state but waiting

to go primary or standby.
WAIT BOOL System
 False: The PAC is in standby, primary, or
stop state.
 True: The PAC is in primary state.
RUN_PRIMARY BOOL  False: The PAC is in standby, wait, or stop System

state.
 True: The PAC is in standby state.
RUN_STANDBY BOOL  False: The PAC is in primary, wait, or stop System

state.
 True: The PAC is in stop state.
STOP BOOL  False: The PAC is in primary, standby, or System

wait state.
 True: The PAC A/B/Clear switch is in “A”

position.
PLC_A BOOL System
 False: The PAC switch is not in “A”
position.
 True: The PAC A/B/Clear switch is in “B”

position.
PLC_B BOOL System
 False: The PAC switch is not in “B”
position.
43

 True: The PAC does not detect any of the

configured Ethernet RIO drops.
 False: The PAC detects at least one

RIO_ERROR BOOL System
configured Ethernet RIO drop.
NOTE: This bit is always false when no

drop is configured.
 True: A valid SD card is inserted.
SD_CARD_PRESENT BOOL  False: No SD card or an invalid SD card is System

inserted.
 True: The local rack configuration is OK.
 False: The local rack configuration is not

LOCAL_RACK_STS BOOL Application
OK (for example, modules missing or in
incorrect slots, etc.)
Unmanaged data added to the application via

REGISTER WORD[0...63] Application
the Exchange on STBY attribute.
Table 5: Local and remote status structure in HSBY DDT
44

3.1.7. M580 redundancy scan cycle
The following figure shows the typical normal scan cycle:
Figure 10: M580 redundant normal scan cycle
The M580 redundant MAST task is periodic. The scan period has to be configured long enough to
avoid application over-run but not too long to minimize the spare time between cycles. This has to
be adjusted to achieve optimum performance. The figure below shows what happens when the
MAST time is set lower than it should be:
45

Figure 11: M580 redundant over-run scan cycle
In the Operation chapter, the optimization of the MAST cycle time is explained.
3.2. Network Design
3.2.1. Subnetting
In our network, we are using routing to manage the network traffic. This requires the network to
be divided into separate subnets, one for RIO, one for DIO cloud, and a separate one for the
control network. The following ranges are selected.
Control unit Control network DIO cloud RIO network
Control unit 1 172.21.10.0 192.168.10.0 192.168.20.0
Control unit 2 172.21.10.0 192.168.11.0 N/A
Table 6: Selected IP network addresses
46

3.2.2. Connections
The following table zooms in on some key parts of the network:
Step Action
The figures show the Ethernet connections to the M580 PAC in control unit one:
Figure 12: Ethernet connections to the M580 PAC
The figures show the Ethernet connections to the M580 PAC in control unit two:
Figure 13: Ethernet connections to the M580 PAC
Table 7: Ethernet network connections
47

3.2.3. Network addresses
The following tables summarize the IP addresses for all the devices in the system:
Control unit one:
Device IP Address Subnet Mask Default Gateway
Primary
192.168.10.1
Main IP Address
Standby
192.168.10.2 255.255.255.0 192.168.10.253
Main IP Address
CPU-A 192.168.10.3
CPU-B 192.168.10.4
CRP-1 192.168.10.11
… … 255.255.255.0 192.168.10.253
CRP-5 192.168.10.15
ATV9xx-1 192.168.10.31 255.255.255.0 192.168.10.253
ATV9xx-2 192.168.10.32 255.255.255.0 192.168.10.253
Primary
192.168.20.101 255.255.255.0 192.168.20.253
BMENOC301
Standby
192.168.20.102 255.255.255.0 192.168.20.253
BMENOC301
BMENOC301-A 192.168.20.103 255.255.255.0 192.168.20.253
BMENOC301-B 192.168.20.104 255.255.255.0 192.168.20.253
STB-1 192.168.20.111 255.255.255.0 192.168.20.253
… … … …
STB-9 192.168.20.119 255.255.255.0 192.168.20.253
48

Primary
172.21.10.253
BMENOC321
255.255.0.0 ---
Standby
172.21.10.254
BMENOC321
Fieldbus network 192.168.10.253 255.255.255.0 ---
Extended network 192.168.20.253 255.255.255.0 ---
Table 8: Control unit one - IP addresses configurations
Control unit two:
Primary
192.168.11.1
Main IP Address
Standby
192.168.11.2 255.255.255.0 192.168.11.253
Main IP Address
CPU-A 192.168.11.3
CPU-B 192.168.11.4
Primary
172.21.10.251
BMENOC321
255.255.0.0 ---
Standby
172.21.10.252
BMENOC321
Fieldbus network 192.168.11.253 255.255.255.0 ---
STB-1 192.168.11.110 255.255.255.0 192.168.11.253
… … … …
STB-9 192.168.11.115 255.255.255.0 192.168.11.253
Table 9: Control unit two - IP addresses configurations
49

Control network:
Server A 172.21.10.1 255.255.0.0 172.21.10.253
Server B 172.21.10.2 255.255.0.0 172.21.10.253
EWS 172.21.10.3 255.255.0.0 172.21.10.253
SW1 172.21.10.11 255.255.0.0 172.21.10.253
SW2 172.21.10.12 255.255.0.0 172.21.10.253
Table 10: Control network - IP addresses configurations
50

3.3. Wonderware System Platform
The key operating principles of the Wonderware System Platform redundancy are described in
the following subsections.
Wonderware System Platform provides two types of redundancy to ensure continued runtime
operation:
 Application: This type of redundancy is intended to protect the system from computer or
software failures, and applies to the Application Engine objects
 Data Acquisition: This type of redundancy is intended to provide the system with a means to
get data from the field using two data sources, and applies to the Device Integration objects
A failover is the condition during which runtime operations are moved from one component to
another. Failover can occur due to failure conditions, or it can be forced manually (forced
failover).
3.3.1. Application redundancy
The application redundancy involves two objects: Windows Platform (WinPlatform) and
Application Engine (AppEngine).
In the deployment context of Wonderware System Platform, the first object required to be
deployed to a computer is the Windows Platform (WinPlatform). This object represents the
computer into the galaxy, hierarchically contains all the other objects to be deployed to a
computer, and controls the starting and stopping of their contained objects. There is only one
Windows Platform instance per computer.
The next object in the deployment hierarchy is the Application Engine. The two main functions of
this object are:
 To serve as a container for all the other types of object instances to be deployed to the
computer
 Determine the scan time within which all contained objects will be executed
Several Application Engine instances can be assigned to a Windows Platform.
51

The following figure represents the hardware components for an Application redundancy:
Redundancy Message Channel

(RMC)
SYNC.
A2 Network
COMPUTER A COMPUTER B
Application Engine 1
Application Engine 1
(Backup)
Windows Platform 1 Windows Platform 2
Bootstrap Bootstrap
PC A PC B
Figure 14: Application redundancy
Each computer is assigned to a Windows Platform object. The primary and the backup
Application Engines are assigned to different Windows Platforms.
Each computer hosting a redundancy-enabled Application Engine must have a minimum of two
network interface cards (NICs). The first NIC is used to exchange information with other
computers in the galaxy (A2 Network), and the second NIC is a dedicated Ethernet connection
between computers for the Redundancy Message Channel (RMC). The functions of the
Redundancy Message Channel are:
 Redundancy monitoring (status)
 Data synchronization
 Current data
 Alarm states and times
 History store
 Deployed objects and configuration
During a failover, when an active Application Engine cannot be successfully executed, it restarts
and the standby Application Engine becomes active. Then, the initially active Application Engine
turns to the Standby mode.
3.3.2. Data acquisition redundancy
Data acquisition redundancy is achieved by using a specific Device Integration object which gets
the data through two I/O device objects. The I/O device objects by themselves do not have
redundancy, but they function as standalone objects. To achieve redundancy on the level of I/O
52

devices, a specific Device Integration object is used, which can use both I/O device objects as
redundant devices.
In our case, two OFS servers will be used on two different platforms. Each OFS server will be
represented in the Application Server by a dedicated I/O device object. A redundant Device
Integration object will use the first OFS server as the primary I/O device, and the second OFS as
a standby I/O device.
Application Object
Active Path Only the OPC ScanGroup Group_1 can

RDIO be managed by the RDIO object,
Backup Path because it has been declared in both
OPCClient objects
Group_1
Group_1
Primary DI source Standby DI source
OPCClient 1 OPCClient 2
Group_1
Group_1 Group_1
Group_1
Group_2
Group_2 Group_3
Group_3
OFS ‘A’ OFS ‘B’
Figure 15: DIOs common scan group
The RDIO also determines which one is active at any given time. Both OPC instances should
have the same scan group configured with the same name.
For more details about Wonderware System Platform redundancy, please refer to the TVDA on
the topic.
53

3.4. System Tools
3.4.1. DTM
In our TVDA, we have three types of DTMs: Master DTM, Gateway DTM, and Device DTM. The
following figure shows the DTM structure, using control unit one as the example, and designation
for our TVDA.
Figure 16: DTM designation
Advantys STB DTM
The DTM for STB devices is linked to the Advantys configuration software as will be explained
further in the configuration section. Accordingly, installing Advantys configuration software on the
same machine with Unity Pro is required in order to use the STB DTM.
Note: The Advantys configuration software can be downloaded from Schneider Electric’s
website. www.schneider-electric.com
54

Altivar Process DTM
Download and install the Altivar Process DTM from Schneider Electric’s website. The first time
that the Unity Pro application is launched after installing the DTM, Unity Pro detects a change in
the hardware catalog and asks for permission to update it.
3.4.2. GPL
The PlantStruxure General Purpose Library (PSx GPL) replaces both the Device Process Library
and the System Library. The PSx GPL has different modules which can be used separately,
according to the selected architecture components. For our TVDA, we will select GPL for Unity
Pro + GPL for WSP.
The control and monitoring components provide the commonly required functions to
communicate and control Schneider Electric equipment and standard process control. The GPL
eases the development of control systems by incorporating hardware diagnostics functions and
reducing possible risks during the programming and configuration phases.
At the control level (PAC), specific Derived Functional Blocks (DFB) are provided.
At the supervision level (SCADA), templates, objects, and faceplates are provided.
The PSx GPL is divided into four categories:
 Communication – The components included in this category are linked to a physical port on
the PAC and, based on a defined algorithm, manage priorities and waiting times, send the
requests to the correct destination, and finally return the corresponding responses to the
devices that generated the requests. The protocols used are Modbus serial-line, Ethernet
Modbus TCP/IP, and CANopen.
 Devices – The components included in this category can communicate with specific
Schneider Electric devices such as soft starters, variable speed drives, power meters, and so
on. These components provide the commonly required functions. Some of these devices
have to be used in combination with the communication port components.
 Process – The components included in this category implement the common functions used
in specific process applications, such as signal conditioning, on/off devices, motorized
valves, sequential controls, and so on. Even though these components are designed to be
independent of the communication used by the equipment they control, some of them can be
used in combination with the device components.
 Diagnostics – The components included in this category gather information from the PAC
(e.g. cycle time, watchdog, clock, and so on) and from the SCADA (e.g. I/O devices or I/O
server status).
55

The PSx GPL libraries are available for download internally. In case you do not have access,
please contact your local Schneider Electric representative for assistance.
3.5. Project Flow

The next chapters will go through project configuration, implementation, and operation. The
Configuration chapter will detail how to configure the different system components. The
Implementation chapter will guide you to implement the system application using the system
components. The Operation chapter will focus on how to start up the system and put it into
operation. It will also guide you on how to properly operate the system and maintain it. The
Appendix contains a table showing the full project flow. You can refer to it to help you organize
your project and connect the different components of the project engineering.
56

OOOO 4 – Configuration
4. Configuration
The configuration of the different components in our high availability system is described in this
chapter, which covers the following parts:
 The M580 HSBY CPUs and communication modules
 DTM configuration for other devices
 ConneXium switches
 Wonderware System Platform
 OFS configuration
4.1. PAC Configuration
4.1.1. PAC hardware configuration
The hardware setup used in this TVDA is composed of two identical PACs for redundancy
capabilities. Each PAC is built with the following elements:
Control unit one:
 One power supply module BMXCPS3500
 One CPU module BMEH584040 (firmware version >= 2.2)
 One NOC DIO module BMENOC0301
 One BMENOC0321

Figure 17: PAC configuration
Control unit two:
 One power supply module BMXCPS3500
 One CPU module BMEH582040 (firmware version >= 2.2)
57

 One NOS module BMENOS0300
 One BMENOC0321

Figure 18: PAC configuration
4.1.2. ERIO drops configuration

Step Action
In the project browser, double click the EIO Bus to open the ERIO bus view, and add your ERIO
drops according to your physical system.
Figure 19: Drops hardware configuration
58

Step Action
In the project browser, double click the EIO Bus to open the ERIO bus view, and add your ERIO
drops according to your physical system. Confirm that your CRA has firmware version >= 2.14.
Figure 20: Adding new ERIO
Select your rack and the corresponding CRA installed. Pay attention to the drop’s topological
address and modify it if needed before creating the drop. This number should match the
configuration of the dip switches in the front of the CRA module, as shown below:
Figure 21: The CRA addressing dip switches
3 Complete the drops configuration by adding the installed power supplies and other I/O modules.
59

Step Action
Add the NOM module and select the right version based on your actual NOM firmware version.
Figure 22: NOM module selection
The first ERIO drop should look like this:
Figure 23: First ERIO hardware configuration
6 Repeat the previous steps and add all your system ERIOs.
Table 11: ERIO drops configuration
4.1.3. CPU configuration
Follow these steps to configure the CPU:
Step Action
Using Unity Pro, open the local configuration editor, select the Device DDT tab, and enter the
1
device DDT name.
60

Step Action
Figure 24: Device DDT name in CPU configuration
Switch to the Configuration tab where you configure the following parameters:
2  The maximum assigned size of addresses for located data
 Enable configuration online modification
61

Step Action
Figure 25: CPU configuration tab
Switch to the Hot Standby tab where you configure the following parameters:
 The run modes (offline or online) of PACs A and B at startup
 The behavior of the standby controller (offline or online) if a logic mismatch is detected
3
between the primary and the standby PACs
 The sections execution in the standby PAC
The following screenshot summarizes our configuration for this TVDA:
62

Step Action
Figure 26: Hot Standby configuration tab
Table 12: CPU configuration
In the Hot Standby tab, there are three different configuration sections, as shown in the picture
above:
 Run Mode: You can select which of the PACs will be online and which one will be offline at
startup.
In our application, we need both PACs to be online.
 Standby On Logic Mismatch: You can decide if the logic mismatch between the primary and
standby is allowed or not. Allowing logic mismatch will allow the standby PAC to remain
running as the standby when there is a logic mismatch. However, the logic mismatch is
limited to a predefined number of modifications. This means that beyond this number of
modifications, the standby PAC will switch from standby state to wait. An application transfer
is needed in this case to allow the standby PAC to run in standby state again.
In our application, we will allow a logic mismatch of up to 10 modifications.
63

CAUTION
Enabling logic mismatch will allow the system to perform switchover even if the standby logic is
different from the primary logic.
It is recommended to enable logic mismatch only during commissioning and online modifications
and disable it at other times.
Note: The logic mismatch parameters can be changed while the PAC is running, using the
Hot Standby DDT.
 Behavior of the CPU in Wait and Standby modes: You can define which sections will be
executed by the PAC when it is running but not in Primary state. There are three options: No
sections to be executed, first section only, or all sections to be executed on both PACs
simultaneously.
In our application, we select to execute the first section only on the standby PAC.
4.1.4. ERIO network configuration
Follow these steps to configure the ERIO network:
Step Action
In the Unity Pro configuration tree, expand the processor sub-port EIO and double click.
Figure 27: EIO port in Project Browser
64

Step Action
In the configuration window, select the security tab and modify your security options.
Figure 28: EIO Communicator Head - Security tab
Enable or disable the required services, according to your application needs. In our application, we
need to enable FTP, TFTP, DHCP, and EIP. We don’t use access control in our example, but you
can configure access control parameters in order to grant predefined services access to specific IP
addresses.
NOTE: The EIP should be activated So the redundancy operates normally. The redundant CPUs
exchange their status on the RIO ring using EIP frames.
65

Step Action
Switch to the IPConfig tab and enter the IP address configuration according to our system design:
Figure 29: EIO network IP address configurations
 Main IP address is the main address that is used by the primary CPU.
 Main IP address + 1 is the main address that is used by the standby CPU.
 IP address A is a dedicated address for CPU A. This address does not change or swap with
the PLC switchover.
 IP address B is a dedicated address for CPU B. This address does not change or swap with
the PLC switchover.
 Gateway is the gateway address that is assigned to this network in the CPU.
66

Step Action
Switch to the NTP tab and configure the service as follows:
Figure 30: NTP service configuration for M580 CPU
In our application, we keep the remaining tab configurations with the default values. They may
4
need to be modified if they are needed in other application requirements.
5 Configure the second system by following the same procedures but using its own IP addresses.
Table 13: ERIO network configuration
4.1.5. NOC DIO configuration
Follow these steps to configure the NOC DIO module:
Step Action
On the rack, right click the selected slot and choose to add a communication module. From the
1
list that will appear, select the BMENOC0301.2.
67

Step Action
A popup window will appear asking for a DTM name. Write a unique name for the inserted NOC
module. This name will be used for the device DDT. This name will also be used later in WSP to
retrieve the NOC status.
Figure 31: NOC configuration DTM window
You can change this name any time in the DTM Browser.
68

Step Action
After you enter the name and close the window, the module will be inserted, and the following
message will appear.
Figure 32: TFTP service notification
This message appears to notify you that the TFTP service is disabled by default. The TFTP
service is needed for the FDR server functionalities and to synchronize both primary and
standby NOC modules.
69

Step Action
In the PLC bus view, double click the NOC module to configure the IP parameters.
Figure 33: NOC DIO IP parameters configuration
 Main IP address is the main address that is used by the primary NOC module.
 Main IP address + 1 is the main address that is used by the standby NOC module.
 IP address A is a dedicated address for the NOC module which is installed on the same
rack with CPU A. This address does not change or swap with the PLC switchover.
 IP address B is the same as IP address A but for the other module.
 Gateway is the gateway address that is assigned to this network in the NOC0321 module.
70

Step Action
In the DTM browser, open the NOC DTM and in the security section, edit these settings:
Figure 34: NOC DIO security options
You can configure access control parameters in order to grant predefined services access to
specific IP addresses.
By default, the backplane Ethernet port is disabled in the NOC DIO module. This is to avoid
overlapping between the processor EIO ring and the NOC DIO rings. This can be checked
through the same DTM window in the switch tap.
Figure 35: NOC module switch configuration in DTM
Table 14: NOC0301 configuration
71

CAUTION
RISK OF BROADCAST STORM
 Do not connect more than one module in a local rack to both the Ethernet backplane and
an Ethernet network. Connecting more than one module to both the backplane and an
Ethernet network can cause a broadcast storm.
 Use only one module in each local rack to connect an Ethernet network to the Ethernet
backplane. That module can be:
 The CPU, when remote I/O are used
 One BMENOS0300
 One BMENOC03•1
72

4.1.6. NOC0321 module configuration
The following table shows the NOC0321 configuration procedure:
Step Action
On the rack, right click the selected slot and choose to add a communication module. From the
1
list that will appear, select the BMENOC0321.
A popup window will appear, asking for a DTM name. Write a unique name for the inserted
NOC0321 module.
Figure 36: NOC0321 configuration DTM window
You can change this name at any time in the DTM Browser.
73

Step Action
In the PLC bus view, double click the NOC0321 module to configure the IP parameters.
Figure 37: NOC0321 IP parameters configuration
 Main IP address is the main address that is used by the primary NOC0321 module.
 Main IP address + 1 is the main address that is used by the standby NOC0321 module.
In the DTM browser, open the NOC DTM, and in the security section, edit these settings:
Figure 38: NOC0321 security options
74

Step Action
In the Services section, enable the IP Forwarding and click Apply.
Figure 39: NOC0321 services
The IP Forwarding sub section will appear under the Services section.
Figure 40: IP Forwarding sub section
Open the Service Port, edit the Service Port Mode, and click Apply.
Figure 41: NOC0321 service port settings
75

Step Action
Now open the IP Forwarding, and edit the network parameters.
Figure 42: IP Forwarding settings
Table 15: NOC0321 configuration
4.1.7. NOM module configuration
Follow these steps to configure the NOM module:
Step Action
In the project browser, expand the EIO drop that contains the NOM module. Double click on the
1
NOM module.
76

Step Action
From the left pane, select Channel 0 and modify the configuration as follows:
Figure 43: NOM module channel configuration
In the DTM browser, under the CPU master DTM, add a DTM named EMX80 GTW DTM. Type
3
the DTM name.
Open the new DTM and go to the Configuration tab. Enter the rack, slot, and channel number.
Figure 44: NOM DTM configuration
Table 16: NOM module configuration
77

4.1.8. Unity Pro project settings
Step Action
To use the components included in the GPL library, configure specific settings in the Unity Pro
project. Activate the following properties in the project settings:
 Allow dynamic arrays (ANY_ARRAY_XXX)
Figure 45: Unity Pro variables project settings

1
 Allow multi assignment [a=b=c] (ST/LD)
 Enable implicit type conversion
Figure 46: Unity Pro program common project settings
78

Step Action
The Data dictionary option is set in the Unity Pro project settings to provide a higher and more
flexible connectivity between Unity Pro and OFS.
The Optimize data on-line change option is also activated.
For better communication management, we can select certain variables to be included in the
data dictionary which will be marked as HMI variables, so the Only HMI variables option will be
enabled, as well.
Figure 47: Unity Pro embedded data project settings
79

Step Action
Activate the Virtual connected mode option in General  Build settings.
This option is used to modify a project on a non-connected terminal, as if this terminal was
connected to the PLC.
It is then simply a case of connecting the terminal to the PLC and activating the command
Build.
 Build Changes in order to have these modifications taken into consideration in the PLC.
This transfer does not stop the PLC, and only the changes made are taken into account. The
purpose of this mode is to inform when an online modification is not possible. However, if the
change is made, the virtual connected mode is aborted.
Note: Analysis is permitted in this mode, but generation is not possible. The project can be
regenerated at any time, but this exits the virtual connected mode.
Figure 48: Unity Pro build settings
Table 17: Unity Pro settings
80

4.2. Field Device Configuration
4.2.1. Altivar Process configuration
The Altivar Process drive is inserted in the ERIO ring using a NOS module and will be scanned
by the CPU as a DIO device. The following table shows the Altivar Process configuration in Unity
Pro.
Step Action
Inside Unity Pro, in the DTM Browser, under the M580 processor DTM, add the device. From
the list, choose ATV9xx then select the protocol used, EtherNet IP, in our case.
Figure 49: Adding a drive using DTM in Unity Pro
81

Step Action
After selecting an Altivar Process drive from the DTM list, a window opens to choose a name for
the inserted drive. This name is the identification of the drive and is used by the DHCP and FDR
servers to serve its IP address and configuration.
Figure 50: Altivar identification name in DTM
Note that this name is used to generate the name of the DDT associated with this specific
device. The DTM automatically creates two DDTs when you build the application.
Double-click the drive in the browser list to select your drive. In the window that opens, select
the appropriate device and its voltage, power, current, and version.
Figure 51: Altivar reference identification in DTM
82

Step Action
Open the DTM of the inserted drive and edit the following configuration:
Figure 52: Altivar I/O profile configuration in DTM
Changing the I/O profile automatically changes the I/O scanning parameters based on
predefined templates. These I/O scanning parameters can still be customized to match your
application needs. Changes in the I/O scanning table are automatically implemented in the
generated device DDT for that device.
According to the motor rating and application requirement, complete all the motor operation and
5 protection settings (like rated speed limits, frequency, power, voltage, current, etc) to assure
proper operation.
83

Step Action
Confirm that you modified the FDR parameters so that the device uses manual synchronization
and stored configuration at first startup.
Figure 53: FDR configuration in the DTM
When a device is inserted in the DTM browser, it is automatically assigned an IP address by the
DTM master. However, you can change the address from the master DTM settings as shown
below:
Figure 54: Changing IP address in DTM browser
84

Step Action
RSTP option is enabled in the default settings of the Altivar 9xx. Confirm this in the dedicated
page in the DTM.
Figure 55: Altivar Process RSTP configuration in DTM
Table 18: Altivar Process DTM configuration
The Altivar Process drives have been configured in Unity Pro, and they are identified by their
names. This enables the DHCP server to identify each device, assign its communication
parameters, and transfer its own settings through FTP after assigning the IP addresses.
To give each drive its name, from the Altivar screen, go to Communication Parameters >
Embedded Ethernet > Device Name. Then use the front panel HMI buttons to assign each
device its own name matching the names defined in Unity Pro.
Note: By default, the drive configuration does not take into account the motor parameters, so you
have to verify in the field that the motor ratings and parameters are correctly defined in the DTM,
according to the real in-field motor nameplate.
Note: The initial command and reference channel for the drive is terminal inputs, not the PAC. As
soon as the configuration has been served to the drive, it will start taking PAC commands into
consideration.
85

4.2.2. STB configuration
Follow these steps to configure the STB devices:
Step Action
This step describes how to add the devices you need to scan – we do not show the configuration
of all the devices in our project because the configuration is directly linked to your project.
The following is an example to add the STB_01 (IP address: 172.21.10.54) using the Unity Pro
DTM – this STB is composed of one DDI3230 module and one DDO3200 module.
From the DTM browser, right click the NOC master DTM to open the contextual menu and select
Add.
Figure 56: DTM browser – Adding a new device
The DTM catalog opens.
From the catalog, select the DTM named STB NIP2x1x.
Figure 57: Adding STB device DTM
86

Step Action
Unity Pro opens the following DTM properties window:
Figure 58: STB device DTM configuration
In the General tab, change the alias name to the name chosen for your device – in our case, we
type STB_01 as the alias name.
Note: Unity Pro uses this name to generate the device DDT instance.
Click OK to validate the DTM instance.
From the DTM browser, double click the NOC master DTM to open the device editor.
Select the new line STB_01 from the Device List menu to edit it:
Figure 59: Editing the newly created DTM
87

Step Action
From the Address Setting tab, change the IP address to the appropriate address, according to
our design.
From the Address Server area, you can optionally activate the DHCP service using the MAC
address or a device name.
We configure the module DTM with the following parameters:
Figure 60: IP parameters of the STB device DTM
6 Complete the STB configuration.
7 Repeat the previous steps to add all the devices.
Table 19: STB configuration
Note: In this TVDA, we only use the STB and Altivar Process DTMs as an example. We
recommend that you read the TVDA, “How can I manage devices with DTMs and M580?” for
more details.
88

4.3. Ethernet Network Configuration
4.3.1. ConneXium switches configuration
A software tool called Ethernet Switch Configurator is used to make the IP address configuration
easier. The Ethernet Switch Configurator is available on the Schneider Electric website.
Launch the software to execute a scan of the network and double click each line to configure the
IP address, netmask, and device name.
The IP addresses are now configured. You can access the web-based interfaces via a standard
web browser (such as Mozilla Firefox or Microsoft Internet Explorer) to complete the configuration
of the switches.
Note: Before configuring a switch, we recommend resetting it to its factory settings to avoid
remnants of any previous configurations. To do this, go to the Basic Settings menu, then the
Load/Save entry, and choose Delete Current Configuration.
Note: To avoid network loops during the configuration phase, configure all the devices for the
RSTP configuration individually. Before you connect the redundant line, you must complete the
RSTP configuration for all the concerned devices in the network.
Proceed as follows to configure the switch:
Step Action
Launch the web browser and enter the IP address 172.21.10.11 to open the embedded web
1
pages of the switch SW1.
Enter the login admin and password private to have the read and write permissions.
2
Click OK to confirm.
From the web-based interface, use the tree control on the left side of the web page and select
Basic Settings  Load/Save.
Figure 61: ConneXium switch configuration load, save, and reset window
89

Step Action
Reset to factory settings – to avoid remnants of previous configurations, we recommend

resetting the switch to its factory settings, as follows: in the Delete section of the page, select
4
Current Configuration, then select Delete configuration.
The existing configuration is deleted from the volatile memory.
Check default RSTP configuration – use the tree control on the left side of the web page and
select Redundancy  Spanning Tree  Global.
Click on Reload to ensure you see the current configuration.
Modify the priority to 0:
Figure 62: SW1 RSTP configuration
Use the tree control on the left side of the web page and select Redundancy  Spanning Tree
 Ports.
Switch off the Spanning Tree Protocol on ports 1, 2, 3, 4, 5, and 6, using the check boxes.
The Spanning Tree port configuration should look like the following:
Figure 63: SW1 STP ports
90

Step Action
Save the configuration – at this stage, the new configuration is only present in the volatile
memory. To preserve these changes in the event of a power loss, the configuration must be
saved: In the Save section, select to Device, then click on Save.
Figure 64: Save configuration to SW1
The configuration of the switch SW1 is now complete.
8 Repeat the same steps for SW2 with RSTP priority 4096.
Table 20: ConneXium switches configuration
The switches are now configured and all the redundant links can be connected.
4.3.2. Servers network configuration
Servers (A and B) have several network card interfaces:
 A single interface for the ArchestrA network
 A single interface for Redundant Message Channel (RMC)
 A single interface for the control network
In computers with more than one NIC, where each NIC is connected to a separate network, it is
possible that the computer DNS registration can occur for unwanted NICs. That can cause
authentication and other issues.
To avoid these issues, you need to set the adapters to allow just one of them to register the
connection’s addresses in the DNS. In this case, the only adapter allowed to register connection
addresses to the DNS is the adapter for the ArchestrA network.
The RMC channel and the control network interfaces require specific configuration. For more
details on the configuration of the system servers, refer to the dedicated TVDA: “How Can I
Implement High Availability Architectures with Wonderware System Platform and PlantStruxure?”
For the control network interfaces, we configure them according to the IP address table. The IP
address of the PC resides in a different subnet than the M580 CPUs. For the PC, any
communication to a subnet other than its own will be forwarded to the gateway. This means that
any request coming from the SCADA to the CPU or DIO device will be forwarded to the
NOC0321 modules. But which NOC0321 module?
For a system with one NOC0321 (one standalone or one redundant pair), that will be an easy
decision as the PC will forward any communication outside its subnet to the NOC0321. But for
91

architectures with multiple systems with NOC0321 and/or external routers, this communication
forwarding has to be managed precisely. The PC has to know which gateway to use for each
specific subnet. This information exists in what is called a “routing table.” The routing table tells
the PC (or a router) where all the packets go when they leave the system. So, we will configure
static routes in the PC to forward each packet to its designated gateway. The following table
shows how to configure static routing for a Windows-based PC:
Step Action
Open the Windows Command Prompt as follows:
 Simultaneously press the Windows button + “R”
 Type “cmd” and hit OK.
Figure 65: Opening Windows Command Prompt
92

Step Action
To view the existing routing table, type the following command and hit Enter:
route print
That will show something like this:
Figure 66: Windows routing table
93

Step Action
To add a static route to the table, we use the following form of command:
 route ADD destination_network MASK subnet_mask gateway_ip metric_cost
The subnet mask and metric cost are optional to the command. If you don’t specify a subnet
mask, it defaults to 255.255.255.255. If you don’t specify a metric cost, it will be assigned
automatically. The metric cost value is just a cost that is relative to other costs in the table and is
used when Windows decides between multiple routes that could reach the same destination. Use
the metric cost to define the priorities of the different routes for the same subnets.
When you add a static route, by default it only lasts until the next time you start Windows. To
make the static route persistent, just add the option –p to the command.
 route -p ADD destination_network MASK subnet_mask gateway_ip

metric_cost
Add one static route for every subnet beyond each NOC0321 module. In our system, we add
three persistent routes for the following subnets:
 RIO ring (192.168.10.0/24)

3  DIO ring 1 (192.168.20.0/24)
 DIO ring 1 (192.168.11.0/24)
To do so, type the following commands (hit enter after each line):
 route –p add 192.168.10.0 mask 255.255.255.0 172.21.10.253
 route –p add 192.168.20.0 mask 255.255.255.0 172.21.10.253
 route –p add 192.168.11.0 mask 255.255.255.0 172.21.10.251
That will look as follows:
Figure 67: Adding static routes in Windows
94

Step Action
Now repeat step two to view the routing table and check your static routes:
Figure 68: Persistent routes in the Windows routing table
Notice that your routes have been added to the persistent routes list.
You might need to remove a static route from your table if you made a mistake or you want to
modify your routes. To delete a static route, use the following syntax:
 route delete destination_network
To modify a persistent static route, use the following syntax:
5  route –p change destination_network MASK subnet_mask gateway_ip

metric_cost
Example code:
 route delete 192.168.10.0
 route –p change 192.168.10.0 mask 255.255.255.0 192.168.10.253
NOTE: The static routes should be configured on the NTP server, as well. In case the NTP server
is not capable of having static routes, an external router is required in order to access multiple
M580 systems with NOC0321 modules.
95

4.3.3. STB network ports redundancy configuration
In the proposed architecture, we implement the Modicon STB NIP 2311 module in an RSTP ring.
Follow the procedure below to enable RSTP on the STB NIP 2311 modules that are part of the
RSTP ring:
 In Advantys Configuration Software, open the STB configuration and double click the STB
NIP 2311 module to edit the parameters
 Select the Redundancy tab, check Enable RSTP and set the bridge priority to 61440
Figure 69: STB RSTP priority
4.3.4. WiFi module configuration
Follow these steps to configure the WiFi module:
Step Action
1 Download and install the ACKSYS Networking Devices Manager (ACKSYS NDM).
Connect your laptop directly to the WiFi module and open the ACKSYS NDM. The WiFi module
will be detected automatically and it will appear on the list.
Figure 70: WiFi module detection in ACKSYS NDM
96

Step Action
3 Open the WiFi module in a web browser and configure your network parameters.
Go to the BASIC tab and navigate to the LAN page. Configure the IP address parameters as
follows:
Figure 71: WiFi module LAN parameters
When you save the configuration, the module will ask for a reboot. Confirm the reboot, and
5
reopen the web browser with the new IP address.
97

Step Action
Go to the BASIC tab and navigate to the WIRELESS page. Configure the IP address
parameters as follows:
Figure 72: WiFi module wireless settings
Personalize your SSID (Wireless Network Name) and password (Pre-Shared Key), as required
in your case.
7 Save the configuration and reboot the gateway.
Table 21: WiFi module configuration
98

4.4. Wonderware System Platform Configuration
The WSP part is covered in a separate TVDA, “How Can I Implement High Availability
Architectures with Wonderware System Platform and PlantStruxure?”, so we will not go through it
in detail here. Please refer to the TVDA for further information about the WSP component.
4.5. OFS Configuration

Schneider Electric’s OPC Factory Server (OFS) is used to link the M580 PAC units and WSP,
using the OPC protocol.
Below is the step-by-step configuration of OFS:
Step Action
Device Alias: M580_1
Create a new device alias, M580_1, which allows communication between the primary PAC and
WSP:
Figure 73: OFS OPC–M580 PAC creation
99

Step Action
Device address
 On the line Device Address, select the square on the right.
Figure 74: OFS OPC–M580 PAC configuration
 In the PLCs area, select UNITY
 Set the IP address to 192.168.10.1
 Set port number to 502
 Click OK
Data Dictionary
Set the data dictionary and dynamic consistency settings as follows:
Figure 75: OFS OPC–Data Dictionary configuration
To access PAC data, OFS uses the data dictionary – theses options allow OFS to automatically
resynchronize the addresses of the variables in case there is an inconsistency following an online
modification applied to the PAC application.
4 In the same way, add M580_2.
Save Configuration
5
From the File menu, click on Save Application.
100

OOO 5 – Implementation
5. Implementation
5.1. Redundant PAC Management

The following steps show the redundancy management in Unity Pro and WSP:
Step Action
In Unity Pro, open Variables & FB instances and create a new variable with the following
parameters:
Name: M580HSBY
1 Type: REF_TO T_M_ECPU_HSBY
Figure 76: M580 HSBY referenced variable
2 In Unity Pro, under Program>MAST>Sections, create a new section named HSBY.
Open the new section and add an instance of REF function block. Add the created variable in
the previous step to the output of this FB. At the input pin, add the M580 HSBY DDDT that is
created automatically by the device DTM. The name will be according to what we entered in the
CPU configuration.
Figure 77: Referencing the host standby variable
Note: In the current version of Unity Pro, the Device DDT cannot be used directly in DFBs. The
REF function is used to reference another variable to the DDDT so this reference can be used
in DFB, as shown in the next step.
Add a new instance of the DFB M580HSBY. Connect the HSBY referenced variable and add the
4
watchdog time to the corresponding pins.
101

Step Action
At the pin labeled A_GENSTS_ST, add a new variable, name it CPU_A_GENSTS_ST, and
press enter. A small window will pop up asking you to create a new variable, confirm the data,
and create the variable.
Figure 78: Creating a variable on the DFB pin entry
Repeat this for all the remaining pins. The variable structure should follow the following format:
CPU_<pin name>
This will be the final layout of the DFB:
Figure 79: HSBY PACs management DFB
Table 22: Redundancy DFB management
In the WSP part, instantiate the M580 HSBY object as follows:
Step Action
Create an instance of the M580HSBY object and rename the two created child instances as
CPU_A and CPU_B.
Figure 80: M580 HSBY instance in WSP
102

Step Action
Open the instance M580HSBY and find the attribute named CONF.HSBY_DDDT. In the Initial
value field, type the same M580 HSBY DDDT variable name as in Unity Pro.
Figure 81: Configuring HSBY instance in WSP
3 Save and close the instance.
Table 23: HSBY PAC instantiation in WSP
On the InTouch WindowMaker side, follow these steps:
Step Action
Click the Embed Archestra Graphic button; select instances from the top filters; find and select
your M580 HSBY instance. From the graphics, choose PACM580H and click OK.
Figure 82: Inserting M580 HSBY graphic
103

Step Action
2 Place the selected graphic where you want it in the window.
If you need to add extra modules or a redundant power supply, follow the previous steps and
3 insert a rack to be placed on the graphic page. Use the rack to host the PAC and any
accompanying modules on top of it.
Table 24: HSBY graphics in Wonderware Intouch
5.2. Redundant Power Supplies

Step Action
1 In Unity Pro, under Program>MAST>Sections, create a new section named PWS.
Open the new section and add an instance of PWS_MGMT function block.
Figure 83: Redundant PWS DFB
At the pin labeled with PWS, add a new variable, name it ERIO01_PWS, and press enter. A
window will pop up asking you to create a new variable. Confirm the data and create the
variable.
3
At the IP_ADDRESS pin, and enter the IP address for where this redundant power supply is
4
installed (the one that this specific DFB is pointing to).
If you have more than one redundant pair of power supplies in your system, add one DFB
5 instance for each pair, input the IP address of the corresponding rack, and give the DDT a
unique indicative name.
Table 25: Redundant power supply management
Note: If you have a redundant pair of power supplies in the local racks, insert two DFBs and use
IP address A and IP address B to point to the power supplies. For the RIO drops, use the IP
address of the CRA module where the PWS is installed.
104

5.3. BMENOC0321 IP Forwarding Management
In our system, the NOC0321 module is the upstream gateway to the PAC. It is important to keep
this access available at all times. In case of a NOC0321 failure, the CPU will not swap
automatically because this is totally dependent on the system requirement. In our system, we
want the PAC to switch over if the primary NOC0321 fails and only if the standby NOC0321 is
ready to take over. The service we are concerned with here is IP Forwarding, so we use the
status of the IP Forwarding service to make the decision. The status of this service is available as
a bit in the device DDT of the concerned NOC0321 module.
For that purpose, the following code is implemented:
Figure 85: Switchover logic in case of primary NOC0321 failure
The swap command has to come from the standby CPU because it is the one capable of
determining the status of the standby NOC. For that to happen, the function blocks used in that
code, as well as their output assigned variables, have to be excluded from the HSBY data
exchange. Not doing that will result in this data being overwritten by the primary CPU, so the
standby CPU will not be able to make the switchover decision. However, the status of the primary
NOC0321 has to come from the primary, so the variable holding this value should always come
from the primary CPU which means it should be part of the exchanged data.
Accordingly, the configuration of the concerned variables and function blocks will look as follows:
Figure 86: Exchange on STBY values for the used variables and EFBs
105

This code will start to engage a switchover in case of IP Forwarding service failure for 100 ms.
After the switchover, the code will be on hold for 10 seconds before going into action again.
These times are subject to change based on your system requirements and the MAST scan cycle
time.
5.4. Modbus Network
5.4.1. NOM module
In Unity Pro, follow these steps to prepare the NOM module for communication:
Step Action
1 In Unity Pro, under Program>MAST>Sections, create a new section named NOM.
Open the new section and add an instance of ModBusPortM58X80 function block. This
function block represents one Modbus port for a NOM module installed in a remote X80 drop.
Figure 87: NOM port function block
At the pin labeled WorkMemory, add a new variable, name it NOM1_P0_WORKMEMORY, and
press enter. A window will pop up asking you to create a new variable. Modify the type field to
ARRAY [0..100] OF INT. The array size will be adjusted later during the project’s fine tuning.
3
106

Step Action
Create integer variables and connect them to the Statistics and WantedArraySize pins.
Figure 89: NOM port function block
5 Add another DFB to use the second port, if needed.
Table 26: NOM module management DFB
5.4.2. Altivar 312

Step Action
1 In Unity Pro, under Program>MAST>Sections, create a new section named ATV312.
Open the new section and add an instance of the MBATV function block. This function block
2
represents a Modbus connected Altivar 312.
At the pin labeled WorkMemory, add the working memory variable corresponding to the
3 associated Modbus port in the NOM module. In our case, it is NOM1_P0_WORKMEMORY.
Add the variable and press enter.
At the pin labeled ModBusAddress, enter the Modbus slave address of the Altivar 312. In our
4
case, the Modbus address of the Altivar 312 is 1.
107

Step Action
Connect the other pins as per your application’s requirements. This is our DFB:
Figure 90: Altivar 312 DFB
Table 27: Altivar 312 management DFB
Repeat the previous steps with all other serial Modbus connected devices, using their dedicated
DFBs and Modbus addresses.
Note: In this TVDA, we use a limited number of devices as an example. We recommend that you
read the TVDAs, “How can I manage devices with DTMs and M580?” and “How can I leverage
seamless integration of Wonderware and PlantStruxure with GPL?” for more details.
108

OO 6 – Operation and Maintenance
6. Operation and Maintenance

This chapter demonstrates the field operation phase of the project. It will go through the following
stages:
 System identification
 Network connection
 Application and configuration download
 System tuning
 System monitoring and operation
 PAC changing configuration on the fly (CCOTF)
 Fast device replacement (FDR)
6.1. System Identification

Identify the reference numbers and firmware versions of all your system components. Check and
modify – if needed – the addresses or device names for the following components:
M580 CPUs setting (A and B)
On the back of each CPU, there is a rotary switch with three positions: A, B, and Clear. Use the
rotary switch to designate the role that the CPU plays in the redundant configuration. Set one
CPU to position A and the other one to position B.
Figure 91: M580 HSBY CPU rotary switches
ERIOs
Identify your Ethernet drops. On each drop head, revise and confirm the address settings. The
address settings should match what has been previously configured in Unity Pro here.
The CRA address is identified by the rotary switches in the front of the CRA module, as shown
below:
109

Figure 92: The CRA addressing rotary switches
DIOs
DIO devices include Ethernet devices and serial Modbus devices. Identify them as follows:
 Altivar Process:
To name each drive, from the Altivar screen panel, go to Communication Parameters >
Embedded Ethernet > Device Name. Then use the front panel HMI buttons to assign each
device its own name to match their names in the Unity Pro DTM.
 STB:
The STB islands are identified by their names which can be modified by rotary switches on
their communication modules. Confirm the identification of each module to match their
names configured with Unity Pro DTM.
 Modbus serial devices:
The Modbus devices are identified by slave numbers. For each Modbus device, go to its
communication parameters and adjust the following parameters:
 Address
 Baud rate
 Parity
 Stop bits
The baud rate, parity, and stop bits should match the Master configuration (NOM port
configuration).
6.2. System Commissioning

The following section will explain how to connect the system, download the application, complete
configuration, and put everything into an operational state. Network connections will be made by
segments, progressively, to ease the initial setup and operation of the system.
M580 redundant PAC
Follow this procedure to download the PAC applications:
110

Step Action
Connect the field network as follows:
Figure 93: Field devices connection step one
Please note that in this step, we don’t close the Ethernet rings, upstream is not yet connected.
Connect your laptop to one of the CPUs using USB and verify the connection in Unity Pro.
Figure 94: Action table graphics
111

Step Action
3 Connect to the PAC and download your application.
From the PLC menu, transfer the application to the standby PAC:
Figure 95: Transferring the project from primary to standby PAC
112

Step Action
Double click on the CPU, open the animation tab to run the standby controller.
Figure 96: Running standby PAC from animation window
Note: To do this step using the DDT, create an animation table, add the HSBY DDDT, and
expand it. Enable the modification and activate the command bit CMD_RUN_REMOTE. This will
run the standby PAC.
6 Connect the Ethernet links numbered 1 to 4.
Confirm that the RSTP function is activated for both Altivar Process drives and then connect
7
Ethernet link number 5.
8 In the DTM browser, store data to all devices.
Table 28: Application download
Network
The configuration of routers is not detailed in this document. However, the configuration files are
included in the project files delivered with this document. Follow these steps to complete the
network commissioning:
113

Step Action
Partially connect the Ethernet network as shown in this figure:
Figure 97: Ethernet network configuration
2 Open Ethernet Switch Configuration and scan your network.
3 Assign the IP addresses to the switches.
Open the web browser and start your device configuration. Start with the routers and then
4
configure the switches.
5 Connect all the remaining cables of the network as per the architecture design.
Table 29: Network components commissioning
SCADA
After connecting everything in the system, you can now deploy your WSP galaxy. This part is
covered in the TVDA, “How Can I Implement High Availability Architectures with Wonderware
System Platform and PlantStruxure?”
After deploying the galaxy, open the runtime client and navigate between windows in the Intouch
Window Viewer. Confirm the system connectivity and operation.
114

Modbus port
While the system is running, go to the section where you placed the NOM port DFB. Check the
WantedArraySize and adapt your work memory accordingly. Please refer to the TVDA, “How Can
I Manage Devices with DTM and M580?”
MAST cycle optimization
At this point, your system is fully configured and connected. When the system is operational, the
following actions are operating simultaneously:
 Primary and standby CPUs are synchronized every scan cycle.
 ERIO drops are synchronized with the MAST.
 DIOs are exchanging data periodically based on the I/O scanning configuration.
 SCADA system is communicating with the control system, pulling data, and pushing
commands.
This case represents the typical system loading for the M580 HSBY PACs. As mentioned earlier
in the Design chapter, the M580 redundant MAST is periodic, and has to be long enough to avoid
application over-run. On the other hand, it should be adjusted to minimize useless spare time
between cycles.
As per our system, only the MAST task is configured. The minimum MAST cycle time (in ms) can
be calculated as follows:
 (# of drops using MAST task) / 1.5 = 5 / 1.5 ~ 4 ms
With DIO devices configured, the minimum cycle time needs to be increased.
Follow these steps to measure and adjust your scan cycle:
Step Action
Use one of the following two options to monitor the MAST synchronization stability:
 Write code to count changes in the MAST_SYNCHRONIZED variable.
 Add the MAST_SYNCHRONIZED variable to the Unity Pro trending tool.
In our case, we have chosen to write code to monitor the synchronization stability.
Figure 98: Unity Pro code to monitor MAST synchronization
115

Step Action
In the animation table, add and observe the following variables:
 %SW30: represents current scan cycle time in milliseconds
 %SW31: represents maximum scan cycle time in milliseconds
 MAST synchronization indication in HSBY DDDT
 MAST_OUT_SYNC: variable to count out of synchronization
 RESET_SYNC_TEST: to reset the counter anytime

2
Figure 99: MAST synchronization monitoring
On the CPU animation page, adjust the time period until the MAST is synchronized, the out-of-
synchronization counter is no longer counting, and the system is stable.
Figure 100: Adjusting scan period online
Table 30: MAST cycle optimization
6.3. System Operation

In this section, we will demonstrate examples of different system operation and maintenance
options.
6.3.1. Operator screen in Unity Pro
This video shows the procedure for adding the operator screen and managing some operations
through it:
116

Video screen capture
Video 1: Using operator screen in Unity Pro
6.3.2. Operation in WSP
This video shows some operations in Intouch Window Viewer:
Video 2: M580 HSBY monitoring in WSP
6.3.3. Web access
Using a standard web browser, you can access information and diagnostics for the PAC, and
monitor redundant operations, DIO statuses, and more data. From the DIO scanning statuses,
you can directly access the web page of any particular DIO. This video demonstrates some web
browser operations:
117

Video 3: Using web browser to access M580 CPU
In the same way, you can access the NOC modules using their IP addresses.
118

6.3.4. Wireless access
You can connect to the system wirelessly using the WiFi access point that is installed in one of
the ERIO drops. You can access the system using your laptop, tablet, or smartphone. You can
access the system using any WiFi-enabled device through its web browser. We will demonstrate
system access using a smartphone.
This table shows the steps required to connect your smartphone to the system:
Step Action
Enable Wireless in your device and scan the available networks.
Figure 101: WiFi network scan and selection
Select your predefined network and enter the password.
Figure 102: WiFi password entry
119

Step Action
Enable advanced options and set IP settings to Static.
Figure 103: Changing IP address settings in WiFi parameters
Enter your device’s IP settings as follows:
Figure 104: Static IP address parameters for WiFi connection
120

Step Action
Confirm your connection to the WiFi network.
Figure 105: Wireless connection verification
Open a web browser on your device. In the address field, enter the IP address of the primary
PAC.
Figure 106: Opening M580 web page
121

Step Action
Use the web browser to monitor different stats and diagnostics of your PAC.
Figure 107: M580 web pages on a smartphone
122

Step Action
You can do the same with Altivar Process, either by using its IP address or from the I/O
Scanner page.
Figure 108: Altivar Process web pages on a smartphone
Table 31: Wireless access using a smartphone
These configuration and screenshots were done using a smartphone running Android v6.0.1.
However, they may differ slightly depending on the smartphone or tablet manufacturer and model
number.
123

6.4. System Maintenance
System modifications may be needed at any point in time while the system is online and
operational. The challenge is to implement the modifications online without interrupting the
running operation. With Unity Pro and Modicon PACs, you can do this using one of two methods:
 Online: Modifications are done while opening Unity Pro, connected to the PAC in online
mode.
 Offline: Modifications are done offline on the built application, then connect to the PAC and
build the changes online.
NOTE: It is advised to not mix offline build and online build in your system. Set your strategy to
only use the HSBY_BUILD_OFFLINE method, or the online modification, especially when adding
new variables.
6.4.1. Change configuration on the fly
In some cases, you may need to change part of the hardware configuration. This feature is called
Change Configuration On The Fly, hereafter referred to as CCOTF.
CCOTF is a feature of Unity Pro with selected Modicon platforms. It allows I/O configuration
changes in the Ethernet I/O drops when the PAC is in RUN mode.
Deleting and adding modules cannot be done at the same time – they must be done in separate
modification sessions, each session corresponding to the modification between two Build
changes operations. Furthermore, only one drop can be modified per session.
In the example below, we modify the configuration of the RIO drop number 2 by replacing the
installed modules with different ones.
We assume that the primary and standby PACs have identical applications, are in RUN mode,
and that Unity Pro is connected to the primary PAC.
Step Action
In Unity Pro, double click the EIO bus from the project browser:
Figure 109: EIO bus configuration – initial state
124

Step Action
Right click the existing analog modules and select Delete Module – a message is displayed.
2
Click Yes to confirm the modification.
If you try to delete a module on another drop during this current session, the following message
is displayed:
Figure 110: Modification already in progress
3 If you try to add a new module in drop 5 during this session, the following message is displayed:
Figure 111: Modification incompatible with the current session
A Build All operation will be required to generate these modifications if you continue after one of
these messages is displayed.
Click the Build Changes button to apply the configuration changes to the primary PAC.
Figure 112: EIO bus configuration – modules removed
125

Step Action
We recommend that you update the standby PAC immediately after you have changed the
primary PAC to ensure a “bumpless” behavior of the Ethernet I/Os in case of switchover.
5 Select Transfer Project from Primary to Standby PLC from the PLC menu, and then use the
HSBY DDDT to run the standby PAC.
The PACs now have identical applications and are synchronized.
To add the modules to drop number 5:
From drop number 5, right click on the free slot and select New Device.
6
Select the BMX DDI 1602 module – a message is displayed.
Click Yes to confirm the modification.
7 Repeat step 6 for slot 2 with a BMX DDO 6402K module.
Click the Build Changes button to apply the configuration changes to the primary PAC.
Figure 113: EIO bus configuration – modules changed
Select Transfer Project from Primary to Standby PLC from the PLC menu to update the
9
standby PAC, then run the standby.
Table 32: CCOTF operation
6.4.2. Offline modifications
The CCOTF is an example of the online modification on a redundant M580 system. However,
there are also different types of offline modifications, as follows:
1. Offline modifications that can be built offline
2. Offline modifications that cannot be built online
The challenge is to keep the system running while applying the system changes. We will
demonstrate different scenarios to apply the changes without stopping the process.
If you are connected online to the PAC and applying modifications, Unity Pro will notify you of the
changes that have to be built offline. Back in the office, you can still modify the project settings so
Unity Pro will still notify you as if you are connected to the PAC. To do so, enable the Virtual
126

connected mode in the project settings before building and downloading the application to
the PAC, as follows:
Figure 114: Virtual connected mode in Unity Pro
WARNING
UNEXPECTED EQUIPMENT BEHAVIOUR
Before transferring a modified application to the standby CPU:
 Examine carefully all the impacts of the modifications on the application.
 Check that the modified application does not have adverse effects on the process.
damage.
127

Scenario one: offline modification in office – build online is possible
In this scenario, we assume to be in the office, with the latest built project on the PAC and the
virtual connected mode enabled. We want to apply a program modification that can be built
online. For example, modifying logic. Proceed as follows:
Step Action
In the field, before downloading the project to the PAC, confirm that the connected virtual mode
1 is enabled. After building and downloading the project, save the built project. Back in your office,
open the last built project on the PAC.
When you apply your modifications, you can analyze the project for errors or warnings. Project
build changes are not possible in virtual connected mode. However, the project can be rebuilt at
any time, but this will exit the virtual connected mode.
Figure 115: Applying offline changes in virtual connected mode in Unity Pro
If any of your modifications have to be built offline, you will receive the following message:
If you confirm this message, the virtual connected mode will be aborted and you will not be able
to build the modifications online.
4 After finishing the modifications, none of which require building offline, save the project.
When you arrive to the field, open the modified project and connect to the primary CPU. At this
5 moment, the build changes option is enabled. Enable logic mismatch and click on build
changes. This will apply the modifications to the primary PAC and keep the redundancy active.
6 From the PLC menu, transfer the project from Primary to Standby.
Go to the CPU animation screen and run the standby PAC; confirm that both CPUs are running
7
with equal applications and are synchronized.
8 Disable the logic mismatch before disconnecting from the PAC.
128

This is a graphical summary of scenario one:
Figure 116: Summary of scenario one for offline modification
Scenario two: offline modification in the field – build offline is mandatory
In this scenario, we assume to be in the field, connected to the PAC and applying modifications
which have to be built offline. For example, adding devices in DTM to the project has to be built
offline. Proceed as follows:
Step Action
1 Connect to the primary CPU, and enable the logic mismatch using the HSBY device DDT.
Open one of the MAST sections that is being executed by both the primary and standby CPUs.
2 By default, if not changed, the first section is executed in both CPUs. Add the
HSBY_BUILD_OFFLINE function block. Enable the input pin ALLOW_MISMATCH.
Build the modification while connected online, transfer to the standby CPU, and run the standby
3
CPU. Confirm that both CPUs are running and synchronized.
129

Step Action
Disconnect from the PAC, apply your modification, build changes.

4 Note: If you rebuild the whole project, you will not be able to transfer the project without
stopping the process.
5 Change the PAC address in Unity Pro and connect to the PAC using IP address A or B.
Confirm that you are connected to the standby CPU, otherwise, swap the controllers from the
6
CPU animation window or from the HSBY device DDT.
Transfer the project to the standby CPU and run. At this stage, the standby CPU will be in Wait
7
state. The system is not redundant, but the primary still controls the process.
For the HSBY_BUILD_OFFLINE function block, enable the input pin ALLOW_MISMATCH. That
8
will force the standby controller from Wait state to Standby state.
Swap the controllers from the CPU animation window or from the HSBY device DDT. Now, the
9
CPU with the new application is running the primary and controlling the process.
Go to the CPU animation screen and run the standby PAC, confirm that both CPUs are running
11
and synchronized.
Disable the logic mismatch and the input pin of the HSBY_BUILD_OFFLINE function block
12
before disconnecting from the PAC.
Note: In this scenario, it does not matter if the virtual connected mode is enabled or not.
This video shows offline modification scenario two:
Video 4: Offline modification - built offline
130

Scenario three: offline modification in office – build offline is mandatory
In this scenario, we assume to be in the office, with the latest built project on the PAC and the
virtual connected mode is enabled. We want to apply a program modification that has to be built
offline. For example, adding a device DTM to the project has to be built offline. Proceed as
follows:
Step Action
Confirm that you have the last built project on the PAC and the connected virtual mode is
1
enabled.
Open one of the MAST sections that is being executed by both the primary and standby CPUs.
2 By default, if not changed, the first section is executed in both CPUs. Add the
HSBY_BUILD_OFFLINE function block.
You can analyze the project for errors or warnings. Project build changes are not possible in
3
virtual connected mode. Do not rebuild the project.
4 Save the project (assume that the project name is TVDA_M580_V1.1.stu).
Now save the project again with a different name (assume that the new project name is
5
TVDA_M580_V1.2.stu).
Add your DTM. You will receive the following message:
Confirm this message. The virtual connected mode will be aborted automatically and the build
changes option will be enabled.
After finishing modification, build changes and save the project.

7 Note: If you rebuild the whole project, you will not be able to transfer the project without
stopping the process.
When you arrive in the field, open the first modified project, connect to the primary PAC, and
8 enable logic mismatch. At this moment, the build changes option is enabled. Click build
changes. This will apply the modifications to the primary PAC.
131

Step Action
Confirm that logic mismatch is allowed, then build the modification while connected online,
9 transfer to the standby CPU, and run the standby CPU. Confirm that both CPUs are running and
synchronized.
Confirm that the logic mismatch is enabled and enable the input pin ALLOW_MISMATCH of the
10
HSBY_BUILD_OFFLINE function block before disconnecting from the PAC.
Open the second project TVDA_M580_V1.2.stu and connect to the PAC using IP address A or
11
B.
Confirm that you are connected to the standby CPU. Otherwise, swap the controllers from the
12
CPU animation window or from the HSBY device DDT.
Transfer the project to the standby CPU and run. At this stage, the standby CPU will be in Wait
13
state. The system is not redundant, but the primary still controls the process.
For the HSBY_BUILD_OFFLINE function block, enable the input pin ALLOW_MISMATCH. That
14
will force the standby controller from Wait state to Standby state.
Swap the controllers from the CPU animation window or from the HSBY device DDT. Now the
15
CPU with the new application is running primary and controlling the process.
Go to the CPU animation screen and run the standby PAC. Confirm that both CPUs are running
17
and synchronized.
Disable the logic mismatch and the input pin of the HSBY_BUILD_OFFLINE function block
18
before disconnecting from the PAC.
Note: In this scenario, if the virtual connected mode was not enabled, the modification cannot be
done remotely without interrupting the process to download the modified application. In that case,
applying the modification without interrupting the process has to be done in the field following
scenario two.
132

O 7 – Validation
7. Validation
The Validation chapter describes the various tests we performed on the architecture 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.
7.1. Functional Tests

This subsection lists and graphically depicts the functional tests performed.
CAUTION
Before you proceed with system testing, confirm that the site is ready to perform tests. Confirm
that the system and equipment response will arrive to safe state, regardless of the test results.
133

7.1.1. Components failure tests
Control network ring – one cable break
Figure 117: Control network ring – one cable break
 Action: One cable break in the control ring
 Expected behavior: The network switches automatically react to use an alternate route.
WSP communications are not impacted.
 System built-in function: Yes – the switches and NOC modules are configured to work in
an RSTP ring.
134

SW1 or SW2 failure
Figure 118: Control network switch failure
 Action: Switch off the power of SW1 or SW2.
 Expected behavior: WSP automatically switches to a redundant path (RDIO object switches
to the redundant DIO).
 System built-in function: Yes – this is redundancy management in WSP.
HSBY link break
Figure 119: HSBY link break
 Action: The HSBY link between the primary and standby CPUs is broken.
 Expected behavior: Primary CPU keeps running as primary, while standby CPU switches to
WAIT state.
135

 System built-in function: Yes – this is one of the redundancy operation principles in an
M580 redundant system.
HSBY link return
 Action: The HSBY link between the primary and standby CPUs is re-established.
 Expected behavior: Primary CPU keeps running as primary, while WAIT CPU switches to
Standby mode.
 System built-in function: Yes – this is one of the redundancy operation principles in an
M580 redundant system.
Primary CPU powered off
Figure 120: Primary CPU powered off
 Action: Switch off the power of the primary PAC.
 Expected behavior: Standby PAC takes over the primary role.
 System built-in function: Yes – this is native system behavior.
Second CPU return after power off
 Action: Return the power to the switched-off CPU.
 Expected behavior: The recovering CPU runs into Standby mode.
 System built-in function: Yes – this is native system behavior.
136

Primary NOC0321 failure
Figure 121: Primary NOC0321 failure
 Action: Disconnect the primary NOC0321 from the rack.
 Expected behavior: Switchover occurs and the standby PAC takes over the primary role.
 System built-in function: No – the developed code is responsible for this behavior.
7.1.2. Functional test results

Test description Expected result Actual result Test pass
Control network ring-one cable break Network reconfiguration Network reconfiguration OK

SW1 failure Network reconfiguration Network reconfiguration OK
SW2 failure Network reconfiguration Network reconfiguration OK
HSBY link break STANDBY CPU to WAIT STANDBY CPU to WAIT OK
HSBY link reconnection WAIT CPU to STANDBY WAIT CPU to STANDBY OK
Primary CPU failure M580 switchover M580 switchover OK
Returning CPU runs as Returning CPU runs as
Return the switched-off CPU OK
standby standby
Primary NOC0321 failure PAC switchover PAC switchover occurred OK
Table 33: Functional test results
7.2. Switchover Impact on System Components
7.2.1. Switchover impact on Altivar Process
The following test will be done to monitor the behavior of Altivar Process following a switchover:
 Action: Switch over the PAC and monitor Altivar Process behavior and communication
status.
137

 Test procedure:
The following table explains the test procedure:
Step Action
1 In Unity Pro, connect to the PAC.
2 Build, download, and run the PAC.
3 Transfer application to the standby PAC and run it.
4 Connect the NetAnalyzer between the Altivar Process drive and the NOS module.
5 Connect your laptop to the NetAnalyzer and start capturing the Ethernet packets.
6 Open the animation table and force switchover a few times.
7 Stop recording the Ethernet packets and export it.
Open the file with Wireshark, follow the packets, and measure the delay that occurred in the
8
Altivar Process communication.
Table 34: Testing switchover impact on Altivar Process
 Test result: The recovery time of the Altivar Process varies between 300 ms and 3.2
seconds.
7.2.2. Switchover impact on DIOs
 Action: Switch over the PAC and monitor STB behavior and communication status.
 Test procedure: Repeat the same steps as with the Altivar Process drive. This time, connect
the NetAnalyzer between the NOC and the STB.
 Test result: The STB recovery in the forced switchover is almost immediate.
7.2.3. Switchover impact on RIOs
 Action: Switch over the PAC and monitor ERIOs behavior and communication status.
 Test procedure: Repeat the same steps as the previous tests. This time, connect the
NetAnalyzer between the CPU and the ERIO.
 Test result: There is no interruption time for the ERIO.
138

7.3. Performance Tests
In this section, we cover the performance tests executed on our selected architectures, including:
 Application Response Time (ART)
 Switchover time of the PAC units
NOTICE
EQUIPMENT DAMAGE
Your actual performance will vary, depending on environment, duty cycle, load type, and other
factors.
Perform your own functional and performance tests that suit the system you are designing and
implementing.
Failure to follow these instructions can result in equipment damage.
139

7.3.1. Test tools
Additional tools we used for our tests include the following:

 Modicon M340 PAC
DIG_OUT
This PAC is used with digital I/O modules so that we
can interrupt the power delivered to certain devices
and manage measurement start and stop signals. Figure 122: M340 PAC
 Hilscher NetAnalyzer
This device can analyze and record Ethernet traffic. It

can also manage physical digital inputs and is very
accurate – its time stamp has a resolution of 10
nanoseconds. Wireshark software is used to analyze
the Ethernet data to create the filters for the
Figure 123: NetAnalyzer
NetAnalyzer.
7.3.2. Application response time
The application response time (ART) is the amount of time it takes for information to be
recognized by the system, and then for the system to react. The following table describes the
different steps of this measurement for the system using Ethernet remote I/Os:
Step Diagram Description
A physical signal is sent to the

remote module on a digital input
1
– this is the start time of the
measurement.
The remote module sends the

2 corresponding information to the
PAC.
The CPU handles the input

3 information and sends a
command to an output.
The PAC sends the

remote module.
140

The remote module processes

the physical digital output – this
5
is the stop time of the
measurement.
Table 35: ART measurement principle for a system using Ethernet remote I/Os
The ART is the time it takes 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 I/O drop, but the
principle of the measurement is the same with distributed I/O modules or any system with inputs
and outputs. All ART measurements are completed with PAC A as the primary PAC, and PAC B
as the standby PAC and running. Each test was performed at least 200 times.
ART theoretical calculations
Each Ethernet RIO input signal packet travels from a RIO drop to the CPU, and the CPU sends
an output signal back to the RIO drop. The time it takes for the CPU to receive the input signal
and effect a change in the output module based on the input is called the application response
time (ART).
In an M580 system, the ART is deterministic, which means you can calculate the maximum time
the CPU uses to resolve a RIO logic scan.
To calculate a maximum ART for an M580 redundant CPU, it is necessary to add an estimate of
the maximum time for a switchover event to the standalone CPU ART calculation.
Using the ART standalone value, follow the following formula to calculate ART for a redundant
CPU:
ART (redundant) = ART(standalone) + 1 MAST cycle + maximum event detection time
NOTE: The maximum event detection time (i.e. the time to detect an event that causes a
switchover) is estimated to be 15 ms.
141

The following diagram displays ART-related events and computation parameters:
Figure 124: M580 standalone ART
The simplified way to measure the response time is the following formula:
ART= CRA->Scanner RPI + (2*CPU_Scan) + 8.8 ms
142

To find the RPI of CRA->Scanner, follow these steps:
Step Action
In the MAST properties, edit the scan time.
Figure 125: Scan cycle configuration
2 Build the application.
In the DTM browser, open the CPU master DTM and check the RPI value.
Figure 126: RPI value for RIO drops
Calculate the ART as follows:

4
ART = 5 + 2 * 10 + 8.8 = 38.8 ms
5 Repeat the previous steps with different scan cycle periods.
Table 36: ART test without switchover
143

ART performance test results without switchover
The table below summarizes the results of our ART tests without switchovers – 500 cycles – with
different scan time periods:
System configuration ART measurements (ms) ART theoretical
MAST HSBY maximum time (ms)

Watchdog RPI MIN AVG MAX
period Data without switchover
10 250 5 20 KB 12.85 22.26 30.41 33.8

20 250 10 20 KB 14.73 30.11 45.5 58.8
50 250 25 20 KB 16.44 52.93 87.48 133.8
Table 37: ART tests results using RIO
System configuration ART measurements (ms)
MAST HSBY
period Data
10 250 60 20 KB 63.9 93.52 123.12

20 250 60 20 KB 63.73 93.55 123.37
50 250 60 20 KB 63.53 100.35 182.34
Table 38: ART tests results using DIO (STB)
The system behaves as expected – the measured ART increases with the scan time and is
always lower than the theoretical maximum value.
7.3.3. PAC switchover time – forced by the application
For a redundant system, the maximum ART should take into consideration the delay induced by a
switchover. So, the maximum ART for a redundant M580 is calculated as follows:
ART(redundant) = ART(standalone) + 1 MAST cycle + maximum event detection time
NOTE: The maximum event detection time (i.e. the time to detect an event that causes a
switchover) is estimated to be 15 ms.
The following table describes the different steps of this measurement – with switchover - for the
system using Ethernet remote I/Os:
144

A physical signal is sent to the

remote module on a digital input
1
– this is the start time of the
measurement.
The remote module sends the

primary PAC.
The CPU receives the input, sets

3 a flag and switchover at the end
of the cycle.
The new primary CPU handles

the input with the flag information
4
and sends a command to an
output.
145

The new primary PAC sends the

remote module.
The remote module processes

the physical digital output – this is
6
the stop time of the
measurement.
Table 39: ART test with switchover
ART performance test results with switchover
The table below summarizes the results of our ART tests with switchovers – 500 cycles – with
different scan time periods:
System configuration ART measurements (ms) ART theoretical
MAST HSBY maximum time (ms)

period Data with switchover
10 250 5 20 KB 24.78 33.7 58.38 58.8

20 250 10 20 KB 33.97 50.86 84.77 93.8
50 250 25 20 KB 67.58 104.04 155.92 198.8
Table 40: ART with switchover test results using RIO
System configuration ART measurements (ms)
MAST HSBY
period Data
10 250 60 20 KB 63.57 93.40 123.15

20 250 60 20 KB 63.99 93.00 123.08
50 250 60 20 KB 123.76 152.52 202.95
Table 41: ART with switchover test results using DIO (STB)
146

 8 – Conclusion
8. Conclusion
Plant downtime is one of the biggest causes of lost productivity. Many plants operate below their
maximum production or throughput potential, often because of inadequate availability. Improving
availability can significantly improve plant productivity and the resulting financial performance.
Plant operators have long considered increased availability and utilization, coupled with
minimized downtime (both planned and unplanned), to be the most effective levers to maximize
productivity.
To provide reliable and safe services, like when operating tunnel infrastructure, water and
wastewater treatment, etc, operators must provide a 24/7/365 non-stop service while battling
constantly changing regulations, new security concerns, and aging facilities.
With the Modicon M580 ePAC, automation architects can meet these challenges with an
affordable, high-availability solution for mid-range to high-end process applications, providing hot-
standby CPUs and redundant power supplies. In addition to the redundancy features, the
Modicon M580 ePAC maximizes uptime with the capability for online configuration changes
without stopping the process.
The new M580 hot-standby ePAC at control level, combined with the award-wining Wonderware
System Platform software at the SCADA level, delivers a comprehensive solution to industrial
challenges.
147

 8 – Conclusion
148

9 – Appendix
9. Appendix
9.1. Glossary
The following table describes the acronyms and defines the specific terms used in this document.
Term Description
Application Response Time – the delay between an event, such as an

ART input changing state or a commanded output, and the system response
to that event
The portion of the control system network where process data is primarily
Control network transferred. It includes SCADA-to-PAC traffic and functional-unit-PAC-to-
functional-unit-PAC traffic
CRA Ethernet RIO adapter module located in each RIO drop
Ethernet RIO adapter module located in a RIO drop with Ethernet-

eCRA
enabled backplane
The portion of the control system network in which field device monitoring
Device network and control traffic is primarily transferred. It includes PAC-to-I/O, PAC-to-
drive traffic, and primary-PAC-to-redundant-PAC traffic
Distributed I/O – Ethernet-enabled devices which can include Schneider

DIO
Electric and/or third-party products
Dual-Ring Switch – a Schneider Electric ConneXium Ethernet switch with

the necessary configuration to support the ERIO main ring, as well as a
DRS DIO or ERIO sub ring, and DIO clouds. Other switching devices are not
permitted in the ERIO network. The DRS is also known as ConneXium
Extended switch
EIO Ethernet I/O
ERIO Ethernet Remote I/O
NOC (NOC DIO) Ethernet communication module
NOC0321 L3 Ethernet communication module with routing functionality
NOS Ethernet switch module on X80 rack
PAC Programmable Automation Controller
149

9 – Appendix
Term Description
Remote I/O – I/O devices used when predictable deterministic

RIO performance is expected. When the physical medium is Ethernet, RIO is
known as EIO or ERIO
Requested Packet Interval – the amount of time between packets of input

RPI
data transmitted by a CRA, expressed in milliseconds
Application Object Server – a computer that hosts one or more

AOS
application engines and associated automation objects
Derived template Any template with a parent template
The entire application – the complete ArchestrA system consisting of a

single logical name space (defined by the galaxy database) and a
Galaxy collection of platforms, engines, and objects. One or more networked
PCs that constitute an automation system. This is referred to as the
galaxy namespace.
An object, which is a unique representation of a template that can exist in

Instance
runtime
Any template or instance found in a galaxy database. A common

Object characteristic of all objects is that they are stored as separate
components in the galaxy repository.
OFS Schneider Electric OPC Factory Server
An object containing configuration information and software templates

Template
used to create new derived templates and/or instances
Device Type Manager – A Device Type Manager provides a unified

structure for accessing device parameters, configuring and operating the
devices, and helping diagnose potential problems. DTMs can range from
DTM
a simple Graphical User Interface for setting device parameters to a
highly sophisticated application capable of performing complex real-time
calculations for diagnosis and maintenance purposes.
Field Device Technology – The Field Device Technology standardizes

the communication and configuration interface between all field devices
and host systems. FDT provides a common environment for accessing
FDT
the devices’ advanced features. Any device can be configured, operated,
and maintained through the standardized user interface – regardless of
supplier, type, or communication protocol.
150

9 – Appendix
Term Description
The portion of the control system network where process data is primarily
Control network transferred. It includes SCADA-to-PAC traffic and functional-unit-PAC-to-
functional-unit-PAC traffic.
The portion of the control system network in which field device monitoring
Field network and control traffic are primarily transferred. It includes PAC-to-I/O, PAC-
to-drive traffic, and primary-PAC-to-hot-standby-PAC traffic.
ATV9xx Altivar Process variable speed drive family ATV900
VSD Variable speed drive
Fast Device Replacement is a function for replacing devices quickly with

FDR minimum work required to retrieve configuration and be in operation with
minimum possible downtime.
The File Transfer Protocol (FTP) is a standard network protocol used to

transfer files from one host to another host over a TCP-based network.
FTP
FTP is built on a client-server architecture and uses separate control and
data connections between the client and the server.
Trivial File Transfer Protocol (TFTP) is a utility for transferring files that is
TFTP simpler to use than the File Transfer Protocol (FTP). It is used where
user authentication and directory visibility are not required.
HTTP (Hypertext Transfer Protocol) is the set of rules for transferring files
(text, graphic images, sound, video, and other multimedia files) on the
HTTP
TCP network. As soon as a web user opens their web browser, the user
is indirectly making use of HTTP.
Dynamic Host Configuration Protocol is a client/server protocol that

automatically provides an Internet Protocol (IP) host with its IP address
DHCP
and other related configuration information such as the subnet mask and
default gateway.
EWS Engineering workstation
Table 42: Glossary
9.2. Bill of Material and Software

The following table summarizes all of the selected hardware:
151

9 – Appendix
Firmware or
Description Reference Function
Software Version
BME XBP 0800 1.10 Rack
BMXCPS3500 - Power supply
BME H58 4040 2.3 Processor

Local PAC
490NAC0100 - SFP
BME NOC0301 2.05 DIO scanner
BMENOC0321 1.01 NOC0321
BME XBP 0800 1.10 Rack
BMX CPS 4002 5.7 Redundant power supply
ERIO special BME CRA 31210 2.14 Drop head

modules PMXNOW0300 5.42.6 WiFi module
BMX NOM 0200 1.5 Modbus master
BMENOS0300 - In-rack switch
STB STBNIP2311 V2 Communication head
ATV 9xx ATV930U07M3 1.2 Altivar Process – Ethernet IP
ATV312 ATV312H018M2 5.1IE57 Altivar 312 – Modbus serial
RSPE35-24044O7T99-
0203 Layer 3 Ethernet managed switches for
SCCV999HHPE3S
Routers routing
RSPM20-
1.101 Extension module
4T14T1SV9HHS9
Switches TCSESM083F23F0 1.31 Layer 2 Ethernet managed switches
Unity Pro Unity Pro XL V12.0-170404A PAC programming software
Wonderware System
WSP WSP 2014 R2 SP1 Supervision software
Platform
OFS OFS for WSP 3.60.3107.0 OPC server
Advantys Advantys 8.0.0.0 STB configuration tool
152

9 – Appendix
Firmware or
Description Reference Function
Software Version
M580 master 2.7.18.0 M580 CPU and NOC module master DTM
EMX80 GTW DTM 1.0.1 NOM module DTM
ATV31 – ATV312 2.0.0.1 ATV312 DTM

DTM
TeSysU 2.8.0.0 TesysU DTM
ATV9xx 1.2.0.0 Altivar Process ATV9xx DTM
Advantys STB 8.0.0.0 STB DTM
Table 43: Bill of material and software
153

9 – Appendix
9.3. Reference Documents
The following table is a list of documents you might want to refer to when more details are
needed.
Document Title Reference
Modicon M580 Hardware Reference Manual EIO0000001578
Modicon M580 RIO Modules Installation and Configuration Guide EIO0000001584
Modicon M580 Standalone System Planning Guide for Frequently

HRB62666
Used Architectures
Modicon M580 Hot Standby System Planning Guide for

NHA58880
Frequently Used Architectures
Modicon M580 System Planning Guide for Complex Topologies NHA58892
Modicon M580 Change Configuration on the Fly User Guide EIO0000001590
Unity Pro System Bits and Words Reference Manual EIO0000002135
Redundant Power Supply Management Functions EIO0000002346
M580 BMENOS0300 Network Option Switch Installation and

NHA89117
Configuration Guide
Modicon M580 BMENOC03x1 Ethernet Communications Module

HRB62665
Installation and Configuration Guide
Altivar Process Library Unity Components User Guide EIO0000002085
PMXNOW0300 User Installation Guide
TVDA - How Can I Implement High Availability Architectures with

Wonderware System Platform and PlantStruxure?
TVDA - How Can I Integrate Altivar Process into PlantStruxure?
TVDA – How Can I Manage Devices with DTMs and M580?
TVDA - How Can I Implement Ethernet Distributed I/O in an M580

Modular Architecture?
Routing Configuration
UM Routing HiOS-3S RSPE
HiOS-3S RSPE (Rail Switch Power Enhanced)
Redundancy Configuration UM RedundConfig HiOS-

HiOS-2S-2A-3S RSPE (Rail Switch Power Enhanced) 2S-2A-3S RSPE
Table 44: Reference documents
154

9 – Appendix
9.4. Project Flow Steps
The following table shows the global project flow with some direct link to other parts detailing
these steps:
Description Remarks
 Select your reference architecture and

components.
1 Prepare detailed system design.  Create detailed system design.
 Define all required hardware and software

components.
 Download and install all the required software

tools.
1 Prepare your system.
 Activate your licenses.
 Install required communication drivers.
 This includes Unity Pro for PAC application

2 Create system applications offline.
and WSP for SCADA part.
 Configure DCOM for communication
Configure your system’s computer management. (Refer to OFS documentation)

3
services and communication.  Configure the network adapters and
communication parameters.
 Identify all the system components in the field.
4 Field identification  Confirm the references and firmware versions.
 Confirm the power connections.
 Configure device names and addresses.
5 Local configuration  Define CPU roles A/B.
 Configure ERIOs addresses.
6 Complete the system commissioning.  Refer to the dedicated procedure.
 Connect galaxy network.
8 Deploy WSP galaxy.  Deploy your galaxy.
 Run the SCADA system.
 Do all the required testing procedures to

Validate system functionality and
9 validate your system’s operation, functionality,
operation.
and performance.
155

9 – Appendix
156

PlantStruxure™, Altivar™, ConneXium™, Unity™, Modicon™, Wonderware®, Intouch®, Archestra® are
trademarks or registered trademarks of Schneider Electric. Other trademarks used herein are the property of their
respective owners.
Schneider Electric Industries SAS Due to evolution of standards and equipment,

Head Office characteristics indicated in texts and images in this
document are binding only after confirmation by our
35, rue Joseph Monier
departments.
92506 Rueil-Malmaison Cedex
FRANCE
Print:
www.schneider-electric.com
Version 2.0 – 06 2017

TVDA How Can I Implement M580 HSBY System V2

Uploaded by

Copyright:

Available Formats

You might also like

TVDA How Can I Implement M580 HSBY System V2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TVDA How Can I Implement M580 HSBY System V2

Uploaded by

Copyright:

Available Formats

How Can I …

Implement an M580 Redundant

Tested Validated Documented Architecture

© 2017 Schneider Electric All Rights Reserved

This document does not replace any specific product documentation.

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

© 2017 Schneider Electric All Rights Reserved

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

Failure to follow these instructions can result in equipment damage.

Before you begin

© 2017 Schneider Electric All Rights Reserved

START UP AND TEST

 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.

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

© 2017 Schneider Electric All Rights Reserved

© 2017 Schneider Electric All Rights Reserved

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

© 2017 Schneider Electric All Rights Reserved

 Turn off all power before working on or inside equipment.

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

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

© 2017 Schneider Electric All Rights Reserved

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

 Design choices for the application – software and hardware architectures

 Test results to confirm the requirements are met

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

Video player requirements

 Adobe® Flash® Player 11 plug-in or higher must be installed in your computer

 The recommended minimum screen resolution is 1280x800

© 2017 Schneider Electric All Rights Reserved

V1 6/2016 Creation of the document

V2 6/2017 Update architecture and adding extra features.

© 2017 Schneider Electric All Rights Reserved

© 2017 Schneider Electric All Rights Reserved

© 2017 Schneider Electric All Rights Reserved

1.2. Customer Challenges

When this is the case, the main challenges are:

 High performance and fast response

 Easier diagnostics, remote access, transparency, and maintainability

© 2017 Schneider Electric All Rights Reserved

 Wonderware System Platform (WSP)

 ConneXium switches and networking

1.4. About this Document

© 2017 Schneider Electric All Rights Reserved

© 2017 Schneider Electric All Rights Reserved

© 2017 Schneider Electric All Rights Reserved

2.1. PlantStruxure Modular Architecture

2.2. Modicon M580 Redundant System Components

© 2017 Schneider Electric All Rights Reserved

2.2.1. Local racks

© 2017 Schneider Electric All Rights Reserved