Water Online

May 2016

Water Innovations gives Water and Wastewater Engineers and end-users a venue to find project solutions and source valuable product information. We aim to educate the engineering and operations community on important issues and trends.

Issue link: http://wateronline.epubxp.com/i/672151

Contents of this Issue

Navigation

Page 32 of 38

they can also greatly simplify the process of synchronizing historical databases across networks in real time. SCADA manufacturers are even starting to incorporate configuration management into their products. In addition to increasing system uptime, these innovations provide an opportunity to build real-time, full-system backups right into your server architecture while simplifying the entire process. The key to this approach is using a software platform where the history, configuration log, tags, and alarms are integrated into the software itself. Configuration — Set up two or more SCADA servers on a shared network. Then, configure a server list to designate the primary server, as well as the order of failover to the other computers. At any given point, only one server should be responsible for polling remote monitoring and control devices. The ease of synchronizing servers will vary from product to product. Once completed, each server should contain an up-to-date copy of the historian and the change log, as well as the tag, alarm, and event databases. In effect, each server is a real-time backup of the whole application — no third-party utilities or databases required. Activities such as trending, reporting, and alarm analysis typically take place on the local server, minimizing network traffic. Disaster backup — If one or more synced servers are located at geographically separate locations, then there is effectively a complete off-site backup in case the primary server or the building where it resides is destroyed. Restored or replaced servers should be able to pull a copy of the running application from any surviving server. Failover scenario – If the primary should go offline for any reason, the next designated server will take over polling and any other duties associated with the primary, such as acting as the thin client server. Configuration changes to displays, settings, and tags will be disseminated to all available computers on the server list. When the primary server resumes its duties, all missed historical and configuration data is bi-directionally backfilled over the network. Example: Municipality of Colchester, Nova Scotia The Municipality of Colchester in Nova Scotia, Canada, uses this approach at four of its sewage treatment plants that collectively service approximately 45,000 residents. Originally, each plant had its own autonomous monitoring and control system. They decided to transition to a single SCADA software platform that would allow them to monitor all four plants and make configuration changes from the main office in Colchester (Plant 1). In the process, they also managed to address long-standing issues with remote data backup and automatic failover. Colchester standardized with software that could communicate with all the various remote programmable logic controllers (PLCs) used at each plant. It also features an integrated historian, change list, alarm manager, and tag database. The Colchester team took this idea a step further. Each plant has its own SCADA application with a local primary server and a synchronized backup at the main office. All four backup applications run concurrently on the same computer. In addition to providing centralized configuration, monitoring, and alarm management, this approach also provides a complete real-time backup of the entire application and its historical data. Should any local server fail, the office backup will take over logging from PLCs at the site. When restored or replaced, the primary is automatically backfilled over the network from the backup. Never Forget Another Backup SCADA backup strategies need to be scalable, comprehensive, and automatic. By building your backup right into your server architecture, you can ensure that you are capturing every part of your system and leaving no gaps in your historical data. n Christopher Little is a member of the marketing team at Trihedral Engineering Limited. He has authored numerous HMI and SCADA articles for print and web- based publications including, Water Online, Everything About Water, and Automation.com . He has also produced a variety of videos discussing different aspects of monitoring and control systems. About The Author 30 wateronline.com n Water Innovations SCADA

Articles in this issue

Links on this page

Archives of this issue

view archives of Water Online - May 2016