StruxureWare Power Monitoring 7.0

StruxureWare Power Monitoring 7.0 System Design Guide 7EN02-0315-00 05/2012

Contents Safety information 5 Safety precautions 7 System Design Guide introduction 9 Supported operating system and SQL Server editions 11 StruxureWare Power Monitoring recommended server specifications 12 Communication networks 13 Ethernet network design 14 LAN topologies 14 Other LAN considerations 17 Physical planning and layout 17 Serial network design 18 RS-232 communications 18 RS-485 communications 19 General bus wiring considerations 20 Other network considerations 21 Additional considerations for high-performance systems 21 StruxureWare Power Monitoring architecture 23 Server types 24 Primary Server 24 Database Server 24 Secondary Server 25 Client types 26 Engineering Clients 26 Web Clients 26 Architecture types 27 Standalone Server architectures 27 Distributed Server architectures 27 System components 29 StruxureWare Power Monitoring services 30 ION site server 32 ION Log Inserter service 34 Virtual ION Processor 34 ION Real Time Data Service 35 Translators 36 StruxureWare Power Monitoring Diagnostics Viewer 37 Starting Diagnostics Viewer 37 Service Diagnostics 37 Communications Diagnostics 38 Additional Commands 40 Using StruxureWare Power Monitoring as an OPC Server/Client 40 Advanced configuration parameters 42 Registry settings 43 Appendix A: Tested Reference Systems 45 Appendix B: Determining when a Secondary server is required 47

StruxureWare Power Monitoring 7.0 System Design Guide Examples 47 Appendix C: Serial Comms test results 48 Appendix D: Data Redundancy 49 SQL Server clustering 49 FAQs 50 Glossary 52 Page 4 of 58 2012 Schneider Electric. All rights reserved.

Safety information Important information Read these instructions carefully and look at the equipment to become familiar with the device before trying to install, operate, service or maintain it. The following special messages may appear throughout this bulletin or on the equipment to warn of potential hazards or to call attention to information that clarifies or simplifies a procedure. Please note The addition of either symbol to a "Danger" or "Warning" safety label indicates that an electrical hazard exists which will result in personal injury if the instructions are not followed. This is the safety alert symbol. It is used to alert you to potential personal injury hazards. Obey all safety messages that follow this symbol to avoid possible injury or death. DANGER DANGER indicates an imminently hazardous situation which, if not avoided, will result in death or serious injury. WARNING WARNING indicates a potentially hazardous situation which, if not avoided, can result in death or serious injury. CAUTION CAUTION indicates a potentially hazardous situation which, if not avoided, can result in minor or moderate injury. NOTICE NOTICE is used to address practices not related to physical injury. The safety alert symbol shall not be used with this signal word. 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, installation, and operation of electrical equipment and has received safety training to recognize and avoid the hazards involved. 2012 Schneider Electric. All rights reserved. Page 5 of 58

Page 6 of 58 2012 Schneider Electric. All rights reserved.

StruxureWare Power Monitoring 7.0 System Design Guide Safety precautions Installation, wiring, testing and service must be performed in accordance with all local and national electrical codes. DANGER HAZARD OF ELECTRICAL SHOCK, EXPLOSION, OR ARC FLASH Apply appropriate personal protective equipment (PPE) and follow safe electrical work practices. See NFPA 70E in the USA or applicable local standards. Any equipment or device associated with this product must only be installed and serviced by qualified electrical personnel. Turn off any power supplying any device associated with this product and the equipment in which it is installed before working on the device or equipment. Always use a properly rated voltage sensing device to confirm that all power is off. Connect protective ground (earth) before turning on any power supplying any device associated with this product. Failure to follow these instructions will result in death or serious injury. UNINTENDED EQUIPMENT OPERATION WARNING Do not use StruxureWare Power Monitoring for critical control or protection applications where human or equipment safety relies on the operation of the control action. Failure to follow these instructions can result in death or serious injury. Note Do not base your maintenance or service actions solely on messages and information displayed by the software. 2012 Schneider Electric. All rights reserved. Page 7 of 58

Safety precautions StruxureWare Power Monitoring 7.0 System Design Guide Page 8 of 58 2012 Schneider Electric. All rights reserved.

StruxureWare Power Monitoring 7.0 System Design Guide System Design Guide introduction The System Design Guide provides an overview of the elements involved in StruxureWare Power Monitoring system design. 2012 Schneider Electric. All rights reserved. Page 9 of 58

System Design Guide introduction StruxureWare Power Monitoring 7.0 System Design Guide Page 10 of 58 2012 Schneider Electric. All rights reserved.

StruxureWare Power Monitoring 7.0 System Design Guide Supported operating system and SQL Server editions The following table summarizes the supported 32-bit and 64-bit versions of Microsoft Windows operating systems and SQL Server editions. 32-bit Windows Operating Systems Windows 7 Professional/Enterprise Editions, SP1 Windows Server 2008 Standard/Enterprise Editions, SP2 Windows Server 2008 Standard/Enterprise Editions, SP2 64-bit Windows Operating Systems Windows 7 Professional/Enterprise Editions, SP1 Windows Server 2008 Standard/Enterprise Editions, SP2 Windows Server 2008 Standard/Enterprise Editions, SP2 Windows Server 2008 R2 Standard/Enterprise Editions, SP1 Windows Server 2008 R2 Standard/Enterprise Editions, SP1 32-bit Microsoft SQL Server Editions SQL Server 2008 R2 Standard Edition, SP1 SQL Server 2008 Standard/Enterprise Editions, SP2 SQL Server 2008 R2 Standard/Enterprise Editions, SP1 64-bit Microsoft SQL Server Editions SQL Server 2008 R2 Standard Edition, SP1 SQL Server 2008 Standard/Enterprise Editions, SP2 SQL Server 2008 R2 Standard/Enterprise Editions, SP1 SQL Server 2008 Standard/Enterprise Editions, SP2 SQL Server 2008 R2 Standard/Enterprise Editions, SP1 Standalone Server Distributed Database Server ü - ü ü Standalone Server ü ü Distributed Database Server ü - ü ü ü ü ü ü ü ü 2012 Schneider Electric. All rights reserved. Page 11 of 58

StruxureWare Power Monitoring 7.0 System Design Guide StruxureWare Power Monitoring recommended server specifications StruxureWare Power Monitoring recommended server specifications The following table provides the recommended server specifications for a StruxureWare Power Monitoring system based on the number of devices in the system and number of concurrent Web Client users. See "Appendix A: Tested Reference Systems" on page 45 for example tested references systems based on these specifications. No. of Devices No. of Users 1-99 < 15 1-99 < 20 100-250 < 20 250-600 < 35 600-1000 < 50 1000-2500 < 50 Power Monitoring software version StruxureWare Power Monitoring v7.0 StruxureWare Power Monitoring v7.0 StruxureWare Power Monitoring v7.0 StruxureWare Power Monitoring v7.0 StruxureWare Power Monitoring v7.0 StruxureWare Power Monitoring v7.0 SECONDARY SERVER Windows Operating System Windows 7 (64-bit) Professional Ultimate Enterprise Server 2008 R2 Standard Enterprise Server 2008 R2 Standard Enterprise Server 2008 R2 Standard Enterprise Server 2008 R2 Standard Enterprise Server 2008 R2 Standard Enterprise Server 2008 R2 Standard Enterprise Database Engine SQL 2008 R2 Standard Edition SQL 2008 R2 Standard Edition SQL 2008 R2 Standard Edition SQL 2008 R2 Standard Edition SQL 2008 R2 Standard Edition SQL 2008 R2 Standard Edition n/a Primary Server details CPU: Quad Core, 8M Cache, 2.8GHz, 4.8 GT/s RAM: 12GB, 1333MHz, DDR3 SDRAM, ECC (3 DIMMS) HD: x2 500GB SATA 3.0Gb/s CPU: 6 Core, 2M Cache, 3.2GHz, 4.8 GT/s RAM: 24GB, 1333MHz, DDR3 SDRAM, ECC (6 DIMMS) HD: x1 500GB SATA 3.0Gb/s; x2 1TB SATA 3.0Gb/s CPU: Quad Core, 12M Cache, 2.4Ghz, 5.86 GT/s RAM: 24GB, 1333MHz UDIMMS (3 DIMMS) HD: x6 300GB 15K RPM SA SCSI 6Gb/s 3.5in Hotplug Hard Drives CPU: x2 Quad Core, 12M Cache, 2.4Ghz, 5.86 GT/s RAM: 24GB, 1333MHz UDIMMS, (6 DIMMS) HD: x6 300GB 15K RPM SA SCSI 6Gb/s 3.5in Hotplug Hard Drives CPU: x2 6 Core, Cache 12M, 2.66Ghz, 6.4 GT/s RAM: 24GB 1333MHz Dual Ranked LV RDIMMs (6 DIMMS) HD: x6 300GB 15K RPM SA SCSI 6Gb/s 3.5in Hotplug Hard Drives CPU: x2 6 Core, 12M Cache, 2.66Ghz, 6.4 GT/s RAM: 24GB 1333MHz Dual Ranked LV RDIMMs (6 DIMMS) HD: x6 300GB 15K RPM SA SCSI 6Gb/s 3.5in Hotplug Hard Drives CPU: x2 Quad Core, 12M Cache, 2.4Ghz, 5.86 GT/s RAM: 24GB, 1333MHz UDIMMS, (6 DIMMS) HD: x6 300GB 15K RPM SA SCSI 6Gb/s 3.5in Hotplug Hard Drives 2012 Schneider Electric. All rights reserved. Page 12 of 58

StruxureWare Power Monitoring 7.0 System Design Guide Communication networks A well designed network is one of the keys to the performance of StruxureWare Power Monitoring. The ability to move data from networked devices to a database or primary server has an impact on system performance. For this reason, choosing the appropriate network type and setup are important steps to an efficient energy management system. In this section: Ethernet network design 14 LAN topologies 14 Other LAN considerations 17 Physical planning and layout 17 Serial network design 18 RS-232 communications 18 RS-485 communications 19 General bus wiring considerations 20 Other network considerations 21 Additional considerations for high-performance systems 21 2012 Schneider Electric. All rights reserved. Page 13 of 58

Communication networks StruxureWare Power Monitoring 7.0 System Design Guide Ethernet network design LAN topologies Understanding basic network structure The physical layout or topology of a network consists of cables, components, and devices. These can be structured in any of the following topologies: Star topology Ring topology Dual ring topology Mesh topology Each topology has its advantages and disadvantages, which are summarized in the following topology descriptions. In addition to choosing the ideal topology, there are other LAN considerations to take into account when planning a robust application network. Star topology In a star topology, all the devices are connected though a central device. A star topology is a common network layout for office environments and also for newer metering environments. In a star topology, devices can use dedicated sections of the network for various services. In an Ethernet star, the intermediate device may be a hub or a switch. For industrial Ethernet applications, the use of a full duplex switch as the central device, rather than a hub, is strongly recommended. Advantages Network throughput is much higher than on a shared-media bus topology. Network reconfiguration is much easier. Centralizing network components makes administration easier; centralized management and monitoring of network traffic enhances network performance. Diagnostics are simple; if a network segment becomes inoperable, it affects only the devices directly connected to that segment. Infrastructure components use monitoring software and device-based Disadvantages Star topologies are more costly because a dedicated cable must be run to each device. To offset this disadvantage, network infrastructure components (switches, hubs, etc.) are used in cabinets on the factory floor so that a group of local devices can be connected together. A single long cable can be run back to a central point to support the group, rather than using separate cables for each device. Page 14 of 58 2012 Schneider Electric. All rights reserved.

StruxureWare Power Monitoring 7.0 System Design Guide Ethernet network design Advantages LEDs to help indicate failures; most single points of failures can be diagnosed and repaired quickly. Resilience; a cable failure should only take that device out of service. You can have more devices on a single network than on a bus topology. Disadvantages Ring topology In a ring topology, all devices or network infrastructure components are connected in a loop with no beginning or end. Packets travel in a single direction on the ring as they are passed from one device to the next. Each device checks a packet for its destination and passes it on to the next device until it reaches its destination. Ring topologies provide redundancy. The loss of a single link is handled by routing traffic in the opposite direction. A ring may be based on token rotation or random/shared access. Alternatively, it may be a switched network where all the devices access the network at the same time at different speeds. Advantages Redundancy; the loss of a single link or infrastructure component does not affect the entire network. A ring topology uses software to monitor the network links. Disadvantages High cost; more cabling is needed to complete the ring. Network infrastructure components need intelligence to respond to device failures; they are more costly than simple bus or star components. Ethernet rings usually form the backbone for high-availability applications. Two paths are available to reach the same device. If ring topology is required, switches that support either a proprietary ring topology or spanning tree protocol (either spanning tree or rapid spanning tree) need to be used. Spanning tree protocol (STP; IEEE 802.1D) or rapid spanning tree protocol (RSTP; IEEE 802.1w) are protocols that avoid communication loops and find a new communication path when the initial path is no longer available. The recovery time (time to find a new path) is approximately 30 s with STP. With RSTP and proper network design, recovery time could be as low as 100 ms. 2012 Schneider Electric. All rights reserved. Page 15 of 58

Communication networks StruxureWare Power Monitoring 7.0 System Design Guide Dual ring topology When used in critical applications, dual ring topology may be deployed to avoid network outages. A dual ring has all the features of a single ring with more fault tolerance. It is comprised of infrastructure components connected together with multiple rings. Each device is connected to two infrastructure components. Each infrastructure component is connected to a separate ring. When a single link or infrastructure device fails, all other devices can still communicate. Dual ring topologies have additional features not always found in typical data communications environments. For example, hot standby links are used between rings. When a link fails, the standby becomes active and prevents any interruption in network communications. Watchdog packets are sent out to inactive connections and create logs if the connection remains inactive. The watchdog packets create log entries that are monitored by the network administrator. Advantages Redundancy; the failure of multiple devices or cables should not cause the network to fail. Separate power supplies can be used for each ring. Multiple interfaces within a device can connect the device to different rings so that the flooding of one ring with collisions or broadcast traffic should not cause the system to fail. Disadvantages Cost, compared to a single ring, since the amount of equipment is doubled The need to regularly monitor unused links so that they are known to be healthy in the event that they are needed. Ethernet rings usually form the backbone for high-availability applications. Two paths are available to reach the same device. If ring topology is required, switches that support either a proprietary ring topology or spanning tree protocol (either spanning tree or rapid spanning tree) must be used. Spanning tree protocol (STP; IEEE 802.1D) or rapid spanning tree protocol (RSTP; IEEE 802.1w) are protocols that avoid communication loops and find a new communication path when the initial path is no longer available. The recovery time (time to find a new path) is approximately 30 s with STP. With RSTP and proper network design, recovery time could be as low as 100 ms. Mesh topology A mesh topology is used in very large networks or network backbones where every end device or infrastructure device has a connection to one or more components of the network. Ideally, each device is directly connected to every other device in the mesh. Page 16 of 58 2012 Schneider Electric. All rights reserved.

StruxureWare Power Monitoring 7.0 System Design Guide Ethernet network design Another mesh implementation is as a network backbone that connects separate star structures. This combined topology provides fault tolerance to the backbone without the high cost of a mesh topology throughout the entire network. Mesh topologies are used less frequently because of cost and complexity. Advantages Fault tolerance; if a break occurs anywhere in the network cable segment, traffic can be rerouted. Disadvantages Complexity; difficult to manage and administer. High cost; more cabling and interfaces are needed to support the redundant connections. An Ethernet mesh network offers more redundancy than an Ethernet ring architecture. In a ring, two paths are typically available to the same device. In a mesh network, more than two paths are typically available. To develop an Ethernet mesh topology, switches that support spanning tree or rapid spanning tree protocol are required. Other LAN considerations Switch and hub configurations work in conjunction with network architecture to help ensure performance. Recommendations for network layout are described below. Full-Duplex vs. Half-Duplex Schneider Electric recommends the use of full-duplex switches wherever possible. Full-duplex switches: give greater bandwidth (100 MB in both directions on certain networks). allow a device to send responses while receiving additional requests or other traffic. result in fewer delays and errors with a device. Switches Switches should always be used in the design of your network. They offer more intelligence than hubs at an equal or lesser cost. The industrial switches available today work reliably under extreme conditions such as electromagnetic interference, high operating temperatures, and heavy mechanical loads. Protect industrial switches by using field-attachable connectors up to IP67 and redundant ring cabling. Physical planning and layout Factors that affect system performance Each of these items can affect system performance: inherent limitations of each communications protocol robustness of the network (for example, number of retries, timeouts, lost packets) response times of the devices in the system 2012 Schneider Electric. All rights reserved. Page 17 of 58

Communication networks StruxureWare Power Monitoring 7.0 System Design Guide type of connection for each device (serially or direct to Ethernet) number of masters requesting information (PowerLogic SCADA, StruxureWare Power Monitoring, PLCs, third party) routing path for each packet (for example, hubs, switches, and gateways) Recommended devices for Ethernet Generally, use switches as much as possible to minimize collisions, increase performance, and simplify network design. Avoid using hubs whenever possible. Installation measure to reduce EMI in Ethernet networks Protecting the Ethernet network from electromagnetic interference (EMI) is an issue that involves the entire installation. Although it is important to be concerned about EMI immunity throughout your entire system, this section describes only methods that apply to your Ethernet network. By equipotentially bonding, grounding (earthing), proper wiring, and shielding your site and equipment, you can significantly reduce a large percentage of EMI issues. The following list describes key measures you need to consider in your installation in order to reduce EMI in an industrial Ethernet network: grounding (earthing) and equipotential bonding EMC-compatible wiring and cable runs balancing circuits cable selection shielding filtering placement of devices placement of wires electrical isolation Serial network design Devices such as power meters may provide serial communications ports which allow data to be extracted by a computer for remote display or analysis. The method used to extract this information is called a communications protocol. While communications protocols vary from device to device, the basic process is similar for all devices. RS-232 communications RS-232 is one of the simplest communications network, allowing you to connect to one device using a maximum cable length of 15 m (50 ft). To connect to more than one device, you need to convert this standard to RS-485. Page 18 of 58 2012 Schneider Electric. All rights reserved.

StruxureWare Power Monitoring 7.0 System Design Guide Serial network design RS-485 communications A typical installation consists of a computer workstation (PC) and a number of devices (also referred to as intelligent electronic devices or IEDs) on an RS-485 communications bus. Shielded twisted-pair cable is used to link the communication ports of all the devices. Since the same pair of wires is shared by all devices, only one device can transmit at a time. If two or more devices attempt to transmit simultaneously, collisions occur and messages are corrupted. Some method must be used to control access to the bus and prevent collisions. Schneider Electric devices use a master-slave process to control access to the RS-485 bus. Each RS-485 communications bus has one bus master device which can be hardware or software. This device initiates all communications transactions. All other devices are slaves, which only respond to a request from the master. A slave never transmits a message without first receiving one from the master. In an StruxureWare Power Monitoring energy management system, usually the PC is the master and the networked devices are slaves. In some cases (for example, a Modbus network), one device can act as master to other devices in the loop. Each device has a unique unit ID: a numeric address that identifies each device on the bus. This allows the master to specify which slave responds to the request. The Unit ID for most meters is a four-digit number. For a PC, the unit ID is generally greater than 10,000, making it nearly impossible for the PC unit ID to be the same as a meter unit ID. The PC (master) must transmit a request to a device (slave) in order to initiate communications. The device then responds by transmitting a response to the master. The following sequence of events must occur in order for communications to be successful: 1. The PC (master) must create and output a valid request packet addressed to a specific meter (slave) existing on that communications channel. 2. The packet must arrive at the intended device intact. 3. The device must respond to the message by building and sending a valid response packet. This packet must be addressed to the master to ensure that another slave does not attempt to interpret the message. 4. The response packet must arrive at the master intact. No communication can occur unless initiated by the master. After sending a request as in Step 1, the master waits a limited time for the slave to respond. If a valid response is not received within this timeout period (for example, the slave has timed out), the master either retransmits the request or moves on to the next slave. From the master's perspective, most communication errors are caused by timeouts. Performance measurement There are a number of parameters that can be measured to indicate the health of the communications system. These include: Error rates: ratio of good packets to bad packets. Throughput: rate of useful data transferred in a given amount of time. Response time: how quickly a slave responds to a request. 2012 Schneider Electric. All rights reserved. Page 19 of 58

Communication networks StruxureWare Power Monitoring 7.0 System Design Guide Straight-Line topology The straight-line wiring method is illustrated below. Note that connections are shown for one RS-485 port only. Each end point of the straight-line bus must be terminated with a ¼ watt resistor (R T ). These termination resistors reduce signal reflections that may corrupt data on the bus. Termination resistors are connected between the (+) and (-) terminals of the device at each end of the bus. The value of the resistor should match the line impedance of the cable. For an AWG 22 shielded twisted pair cable, values between 150 and 300 ohms are typical. Consult the cable manufacturer s documentation for the exact impedance of your cable. General bus wiring considerations DANGER HAZARD OF ELECTRICAL SHOCK, EXPLOSION, OR ARC FLASH Apply appropriate personal protective equipment (PPE) and follow safe electrical work practices. See NFPA 70E in the USA or applicable local standards. Any equipment or device associated with this product must only be installed and serviced by qualified electrical personnel. Turn off all power supplying all devices associated with this product and the equipment in which it is installed before working on the device or equipment. Always use a properly rated voltage sensing device to confirm that all power is off. Connect protective ground (earth) before turning on any power supplying this device. Replace all devices, doors and covers before turning on power to this equipment. Failure to follow these instructions will result in death or serious injury. Devices connected on the bus, including meters, converters and other instrumentation, must be wired as follows: Connect the shield of each segment of the cable to ground at one end only. Isolate cables as much as possible from sources of electrical noise. Page 20 of 58 2012 Schneider Electric. All rights reserved.

StruxureWare Power Monitoring 7.0 System Design Guide Serial network design Use an intermediate terminal strip to connect each device to the bus. This allows for easy removal of a device for servicing if necessary. Install a ¼ Watt termination resistor (RT) between the (+) and (-) terminals of the device at each end point of a straight-line bus. The resistor should match the nominal impedance of the RS-485 cable (typically 120 ohms consult the manufacturer s documentation for the cable s impedance value). For additional information regarding the wiring of Schneider Electric devices, refer to the appropriate installation document for each device. Other network considerations The network bandwidth necessary for the communication to the devices is dynamic. There are three types of transactions to the devices that consumes network bandwidth: Periodic polling and uploading of new data log records as well as waveform captures (if available on the device) Real-time data request through StruxureWare Power Monitoring tools (for example, OPC-DA Server, Vista, Designer etc.) Power quality events if available During steady-state operation, StruxureWare Power Monitoring requires a certain amount of bandwidth. This is due to the periodic polling by the Log Inserter to check if there are any new records to upload and then uploading data records. In addition, use of StruxureWare Power Monitoring tools contributes to network consumption. For example, every time a Vista diagram is updated, or Designer connects to a device, there is more network traffic on top of steady-state operation as relevant services interact with the requested devices. This need is linearly related to number of objects being polled on the screen or OPC tags being broadcast. Furthermore, use of VIP and software based logging generates more network traffic. It is important to note that high end power quality meters generate waveforms. These waveforms can be much larger in size compared to the regular data logs. Because the frequency of events and associated waveforms is high, there is a considerable amount of extra communication compared to steady-state operation. It is important to consider this need when using high end power quality devices where power quality events are expected or frequent. Additional considerations for high-performance systems There are a number of items to pay attention to when maintaing a high performance system: Keep serial loops as short as possible. Have a minimum baud rate of 19.2k. Keep the number of devices in a serial loop under ten when using ION protocol, and six when using Modbus. Disable devices that are not presently commissioned or functional (for example defective or physically not connected devices etc.). 2012 Schneider Electric. All rights reserved. Page 21 of 58

Communication networks StruxureWare Power Monitoring 7.0 System Design Guide Device logging is preferable to software-based logging. If on-board logging is not available, use of a data logger (for example, EGX 300), especially on a serial loop can increase the system performance. If possible, connect high-end PQ meters which can generate events and waveforms directly to the Ethernet. If this is not possible, try to isolate them to a smaller serial loop (one or two devices, for example). Do not log measurements that are not needed. When using StruxureWare Power Monitoring as an OPC server, disable tags that are not needed. For devices/sites that are not used for real-time data, use Connection Schedules. If you require high-speed performance from your devices, connect them directly to Ethernet. For custom built 3rd party Modbus devices, adjust Maximum number of registers for a single request as well as Requested update period available in Modbus Device Importer accordingly for optimum performance. See "Chapter 7: Modbus Device Importer" of the StruxureWare Power Monitoring User Guide for additional information. Investigate the network and work on getting communications as error-free as possible. Page 22 of 58 2012 Schneider Electric. All rights reserved.

StruxureWare Power Monitoring 7.0 System Design Guide StruxureWare Power Monitoring architecture This section discusses the different server, client, and architecture types that can be used when setting up StruxureWare Power Monitoring on your network. In this section: Server types 24 Primary Server 24 Database Server 24 Secondary Server 25 Client types 26 Engineering Clients 26 Web Clients 26 Architecture types 27 Standalone Server architectures 27 Distributed Server architectures 27 2012 Schneider Electric. All rights reserved. Page 23 of 58

StruxureWare Power Monitoring architecture StruxureWare Power Monitoring 7.0 System Design Guide Server types A StruxureWare Power Monitoring system may include multiple machines, each playing different roles. There are various types of hardware configurations which include Distributed Systems and Primary Standalone Systems. The roles of computers in a StruxureWare Power Monitoring system include: Primary Server Database Server Secondary Server Engineering Clients Web Clients Primary Server Database Server The Primary Server hosts a collection of services and configurations vital for the functioning of the system. Every StruxureWare Power Monitoring system, no matter how simple or complex, has only one Primary Server. The Primary Server uses Microsoft Internet Information Services (IIS) to make information available to StruxureWare Power Monitoring Web Clients and IIS components (optional components of Windows operating systems). The Web Reporter component is based on Microsoft SQL Server Reporting Services (optional components of SQL Server) and can be installed either on the Primary Server or the Database Server (but not both). The Primary Server can also host the Microsoft SQL Server database engine with the StruxureWare Power Monitoring and Reporting Services databases. When the SQL Server database engine is installed on the Primary Server, it is called a Standalone server. However, an independent server can be used to host SQL engine which is called a Database Server. This type of installation is used in conjunction with the Primary Server and is referred to as a Distributed Database Server installation. StruxureWare Power Monitoring relies on Microsoft SQL Server as a data repository and reporting is handled through SQL Server Reporting Services. The Primary Server can host the Database Server, however, it is possible to use the Distributed Database Server architecture for larger systems as SQL Server is very memory and disk intensive software. Based on the frequency of the SQL transactions, consumed computer resources can be very drastic. Separating the Database Server would mean off-loading this system load from the Primary Server, providing more system resources for core StruxureWare Power Monitoring applications. It is recommended that a 64-bit SQL Server along with a 64-bit operating system be used as it greatly improves SQL Server performance. Page 24 of 58 2012 Schneider Electric. All rights reserved.

StruxureWare Power Monitoring 7.0 System Design Guide Server types Beyond performance, there may be additonal considerations where a distributed database server may be necessary. Reporting Services can only be pointed to a single database, so it is important to be able to hold a large active ION_Data database if generating reports for a long time span is important. If there is a dedicated database server that is required by the IT department, policy may dictate server separation. If redundancy is a requirement, it can be met by using third party tools. Determine if there are specific IT rules that are mandatory for databases (for example, SQL jobs, back-ups, security). Database size considerations Database growth size is dependent on what is stored in the database. As the number of records and measurements that users want to log vary, so can the database size. Additionally, recording PQ events and waveform captures (where available) are event driven, so it is impossible to predict the frequency of these records. Each log holds 75 bytes of hard drive space (This number is only valid for interval data, not for waveforms). From these values it is possible to calculate database daily growth based on number of records logged at every interval. Furthermore, there is a stored procedure called sp_spaceused which returns number of rows and their total size. This stored procedure can also be used for tracking the database growth. With this information, we can determine the database daily growth rates when the factory default framework is used with no PQ events: ION 86xx Device Type 600KB per day per meter Daily Growth Rate ION 76xx 600KB per day per meter ION 73xx 410KB per day per meter PM 8xx 400KB per day per meter CM 3000 763KB per day per meter CM 4000 800KB per day per meter Note These numbers may change with the framework enhancements and should only be used as an estimated baseline. For optimum performance, have 30% free disk space for regular SQL operations. Secondary Server StruxureWare Power Monitoring system architecture supports the ability to distribute additional communication servers when needed. These servers are known as Secondary Servers. Secondary Servers are used to reduce the ION SiteServer load on the Primary Server (The table in "Appendix B: Determining when a Secondary server is required" on page 47 can assist in determining if a Secondary Server is required). Secondary Servers can also be added when multiple instances of VIPs are used. Note that there is only ever one ION RealTime Data service which runs on the Primary Server. 2012 Schneider Electric. All rights reserved. Page 25 of 58

StruxureWare Power Monitoring architecture StruxureWare Power Monitoring 7.0 System Design Guide StruxureWare Power Monitoring s VIP function may be heavily utilized. As explained in the VIP section (see "Virtual ION Processor" on page 34), there are some guidelines around how to use VIP and when to create multiple instances of it. It is possible to use a Secondary Server when no system resources are left for more VIP instances. Client types Engineering Clients Web Clients A Database Server B Primary Server C Secondary Server D Devices Client installations are workstation access points for power users who need the graphical user interfaces (Management Console, Vista and Designer) to do a variety of tasks including running other utilities, adding new devices to the system, configuring devices, viewing and acknowledging system alarms, building power monitoring HMI screens in Vista and more. These client access points require a Client License and they can only be installed after the Primary Server is installed. StruxureWare Power Monitoring Web Clients provide convenient access to the Web Applications via a web browser. Any computer running a supported web browser that has network connectivity to the StruxureWare Power Monitoring Primary Server may function as a Web Client. IIS components and SQL Server Reporting Services components must be installed and properly configured at the StruxureWare Power Monitoring server for full Web Client functionality. Microsoft SilverLight must also be installed on the client machines to be able to use Web Applications. StruxureWare Power Monitoring will prompt you to install Silverlight if it is not present on your system. Page 26 of 58 2012 Schneider Electric. All rights reserved.

StruxureWare Power Monitoring 7.0 System Design Guide Architecture types Architecture types Standalone Server architectures A Standalone Server has all the StruxureWare Power Monitoring software installed on one computer. There is an option to use Engineering and Web Client computers with Primary Standalone systems. In some situations, it is possible and even advantageous to distribute these components to a separate system. Distributed Server architectures A Distributed system is one that has components of StruxureWare Power Monitoring installed on multiple machines. Here are three examples of distributed system configurations: Primary Server, Database Server, Engineeering Clients (optional) and/or Web Clients (optional). A Database Server B Primary Server C Engineering Client (Optional) D Web Client (Optional) E Devices 2012 Schneider Electric. All rights reserved. Page 27 of 58

StruxureWare Power Monitoring architecture StruxureWare Power Monitoring 7.0 System Design Guide Primary Server, Database Server, Secondary Server, Engineering Clients (optional) and/or Web Clients (optional). A Database Server B Primary Server C Secondary Server D Engineering Client (Optional) E Web Client (Optional) F Devices Primary and Database on same server, Secondary Server, Engineering Clients (optional) and/or Web Clients (optional) A Database/Primary Server B Secondary Server C Engineering Client (Optional) D Web Client (Optional) E Devices Page 28 of 58 2012 Schneider Electric. All rights reserved.

StruxureWare Power Monitoring 7.0 System Design Guide System components This section describes the different parts of the StruxureWare Power Monitoring system, including Services and Web Applications. In this section: StruxureWare Power Monitoring services 30 ION site server 32 ION Log Inserter service 34 Virtual ION Processor 34 ION Real Time Data Service 35 Translators 36 StruxureWare Power Monitoring Diagnostics Viewer 37 Starting Diagnostics Viewer 37 Service Diagnostics 37 Communications Diagnostics 38 Additional Commands 40 Using StruxureWare Power Monitoring as an OPC Server/Client 40 2012 Schneider Electric. All rights reserved. Page 29 of 58

System components StruxureWare Power Monitoring 7.0 System Design Guide StruxureWare Power Monitoring services Many of StruxureWare Power Monitoring s core components run as Windows Services. This allows StruxureWare Power Monitoring to continue monitoring your power management system when no users are logged on. As these components play a critical role in the operation of StruxureWare Power Monitoring, it is important to understand what they do. The table below outlines the StruxureWare Power Monitoring Services: Note ION Network Router Service has many dependent StruxureWare Power Monitoring services. For example, the Virtual Processor, ION Log Inserter Service, and ION Site Service cannot start and operate without ION Network Router Service running. ION Alert Monitor Service Name ION Component Identifier Service ION Connection Management Service ION Event Watcher Service ION Log Inserter Service ION Network Router Service ION OPC Data Access Server ION Power Quality Aggregation Service ION PQDIF Exporter Service ION Query Service ION Real Time Data Service ION Report Subscription Service ION Site Service ION Virtual Processor Service ION XML Subscription Service Description Checks the computer s communications ports continuously for high priority events occurring at remote modem sites. When this happens, Alert Monitor initiates a communications connection to the remote modem site. Locates local and remote StruxureWare Power Monitoring components. Determines the connection status of sites and devices in the system, and handles allocation of resources such as modems. This service manages the state of site and device connectivity for the system. In order to establish the most appropriate state for the system, each connection and disconnection request is evaluated against the overall state of the system and availability of communications channels. Monitors system events for conditions specified in Event Watcher Manager. Provides historical data collection and storage for your power-monitoring system. Routes all information between components, such as client workstations and the Log Inserter. The service dynamically detects changes to the network configuration, including the addition of new servers; it can also recognize new software nodes, such as Vista, that are added to an existing server. Manages and is responsible for supplying OPC data to client applications. Periodically processes and aggregates new Power Quality event data. Translates data from databases to PQDIF file format and manages scheduled PQDIF exports. Provides historical data retrieval for your power-monitoring system. Manages and provides access to real time data from the power management system. This service manages Web Reporter report subscriptions. Manages communication links to and from StruxureWare Power Monitoring. ION Site Service is responsible for handling packet communications to system devices and controlling direct device communications. The service reacts to changes in network configuration: for example, often changes to certain channels, gates, ports, or device parameters can interrupt a connection. Provides coordinated data collection, data processing, and control functions for groups of meters. Manages subscriptions to XML data for Vista user diagrams. This service is used only by Diagrams. When you open a Vista user diagram in a web browser, the ION XML Subscription Service creates a subscription and delivers the real-time data in XML format. Page 30 of 58 2012 Schneider Electric. All rights reserved.

StruxureWare Power Monitoring 7.0 System Design Guide StruxureWare Power Monitoring services Service Name ION XML Subscription Store Service Schneider Electric Service Host (CoreServicesHost) Schneider Electric Service Host (DataServicesHost) Schneider Electric Service Host (ProviderEngineHost) Description Stores XML data subscriptions for the power monitoring devices on the network. This service is used only by Diagrams. Hosts the Windows Communication Foundation web services for the Web Application Framework core. The core web services include configuration, web service inventory, diagnostic, and metadata services. Hosts the Windows Communication Foundation web services for the Application Framework Data Source Driver. This web service interacts with the underlying data contained in the ION_Network and ION_Data databases on behalf of the Web Application Framework. Hosts the Windows Communication Foundation web services for the Application Framework Provider Engine, and runs the work ticketing service that controls requests for data aggregation, device lists, and other data requests from the Web Application Framework UI. ION Network Router, LogInserter, RealTime Data and SiteServer services particularly play an important role in data flow and system performance. The following diagram shows how these services interact with each other and the metering devices: Figure 1 ION Services 2012 Schneider Electric. All rights reserved. Page 31 of 58

System components StruxureWare Power Monitoring 7.0 System Design Guide ION site server ION LogInserter service, ION RealTime Data service, Vista and VIP all communicate with the ION SiteServer service via the ION Network Router Service. The ION Network Router Services passes messages (ION programs) back and forth. Vista and VIP directly communicate only with ION SiteServer service for non-real-time values, such as setup register changes. Therefore, not many requests come directly to the ION SiteServer service from Vista and VIPs. ION LogInserter service sends requests to the ION SiteServer service asking it to retrieve data from the devices. ION SiteServer requests position counts, which let ION LogInserter know if there are new logs on a device that need to be collected. It also sends a request for the aggregate setup count which tells it if setup changes have occurred. Finally ION SiteServer sends requests for data records. Polling and aggregate counter requests are sent in the same packets, so there is minimal additional overhead. ION RealTime Data service sends requests for real-time data that its clients (Vista, VIP, OCP Client) have requested of it. The ION SiteServer service has a pool of threads that it manages. It uses these threads to service requests. ION SiteServer also has a queue of requests for each site. ION SiteServer allocates a thread to a site and sends a request from that site s queue to the translator. It waits for a response, failure or timeout. It sends responses to the appropriate requestor via the ION Network Router Page 32 of 58 2012 Schneider Electric. All rights reserved.

StruxureWare Power Monitoring 7.0 System Design Guide StruxureWare Power Monitoring services service. ION SiteServer waits the amount of time specified by the configurable parameter Receive Timeout (Under Advanced properties for the device or site in Management Console) for a response from a device before tracking the attempt and then moving on to a new request for that site. The thread is deallocated and put back in the thread pool. The thread then gets reallocated to a new site and a new request from the site s ION SiteServer queue. ION SiteServer retries sending requests to a device that does not respond the number of times specified by the configurable parameter Attempt Increment (Under Advanced properties for the device or site in Management Console) before it reports a communication failure. The communication failure is logged in the System Log. ION SiteServer also tracks the number of times there is a communication failure with a device. After the number of communication failures specified by the configurable parameter called Maximum Attempt Multiple (Under Advanced properties for the device in Management Console) have occurred ION SiteServer considers the device Offline. For example, the Attempt Increment parameter is set to three and the Maximum Attempt Multiple parameter is set to two. After three attempts to send a request to a device without receiving a response before the specified time out, the ION SiteServer service logs a communications failure. After doing this a second time and getting another communications failure, the device is marked offline. No new attempts to connect to a device in the Offline state are made until the time specified by the configurable parameter Offline Timeout Period (Under Advanced properties for the device in Management Console) has elapsed. The number of threads available for use by ION SiteServer is a configurable parameter called ConnectedThreadPoolSize. See "Advanced configuration parameters" on page 42 for additional information regarding this registry setting. The queues managed by ION SiteServer for each site configured in Management Console use the following priorities: Control sources of these requests are: VIP Distributed Control Module Control functions executed through Vista One Shots sources of these requests are: ION LogInserter data requests Designer updates, for ION meters only Rebuild of trees on restart of StruxureWare Power Monitoring Polling Programs sources of these requests are: ION RealTime Data service requests ION LogInserter log position counter requests ION LogInserter aggregate setup counter requests The ION RealTime Data Service and ION LogInserter both use hybrid programs for polling requests, so they are not true one shot requests. Essentially these hybrid programs are one shots that are processed in the High, Medium, or Low Polling Program queues so they run at lower priority than true one shots. By default, all Polling Program clients are set to a low frequency. 2012 Schneider Electric. All rights reserved. Page 33 of 58

System components StruxureWare Power Monitoring 7.0 System Design Guide ION Log Inserter service The Log Inserter is responsible for data storage. Log Inserter interacts with the other ION services as indicated above to upload and store historical events and data captured by power meter devices and VIPs. Log Inserter continuously polls the devices where logging is enabled to check if there is a new record to retrieve. At communication bottle-necks, such as serial loops or slow communicating meters/sites, if the services cannot interact with the devices in a timely manner, system performance can be affected. This is why a well designed network is important in StruxureWare Power Monitoring systems and network design suggestions should be taken into consideration. See "Additional considerations for high-performance systems" on page 21 for more information. In addition, Log Inserter has a System Log Controller that could be used to partially control what is being retrieved and stored in the database. The Cutoff setup register available in the System Log Controller module filters out events that are below a certain priority. This parameter can be tuned based on what events are considered as low priority and should not be logged. Virtual ION Processor The Virtual Processor (VIP) is a service that operates on the StruxureWare Power Monitoring server, providing coordinated data collection, data processing, and control functions for groups of devices. The Virtual Processor is like a virtual device, capable of collecting and processing data from several power monitoring devices, analyzing the information and performing control functions. The VIP runs in the PC, not as a remote device and contains a wide selection of ION modules, which it uses to process information. A VIP acts as both a client and a server. As a client, it collects data from meters via the ION RealTime Data service. This data can be monitored or used in calculations to produce new data that can, in turn, be logged. As a server, a VIP interacts with other parts of the software in a similar manner to a device. Real-time data can be viewed in Vista or requested via OPC and historical data can be uploaded and stored by the IONLogInserter service. Typically, a VIP requests data from the ION RealTime Data service. In this case, the VIP is the client. There can be multiple instances of VIP service running on a server. It is recommended to split up VIPs as opposed to having one very loaded VIP instance for performance considerations. The limiting factor is based on the size of the VIP files (for example, vip.cfg and vip.bak files) rather than hard number limits on modules. The vip.cfg and.bak files should be at a maximum of approximately 2 MBs in size (This is approximately 350 fully loaded Arithmetic Modules). Page 34 of 58 2012 Schneider Electric. All rights reserved.