1. VTS INNOVATOR SERIES Real Problems, Real solutions

2. Voices from the end user “My data has gaps.” “My reports have different data when I run them on different servers.” “I’m collecting too much data and filling up my server’s hard drive.” “My Historian server needs maintenance. I still need to collect data.”” “I want each of my plants’ historical data from a centralized location.” “I want an industry standard database (SQL, Oracle, etc.)” “I want standardized methods to access my historical data” - And the granddaddy of them all - “My Historian Server has failed! How do I get my data back?“

3. Boiling down the issues Lack of historian redundancy Lack of synchronization (replication) between Historian servers Unreliable networks (wireless, legacy) Low bandwidth networks (shared, overloaded) causing interruptions and inhibiting offsite storage Some data requires short term storage, some requires long term Lack of centralized access to distributed historians Lack of support for industry standard data server platforms Lack of support for standard data access protocols

4. Typical SCADA Application Network Architecture Scenarios

5. Single location, single computer Low server loading allows single computer to be configured as both App. Server and Historian Server Use separate non-RAID hard drive configuration for Historian storage. Frequent read/write access can cause speed issues on RAID. Redundancy unavailable. Use offline data backup.

6. Single location, multi-computer Each computer configured as both I/O Server and Historian Server. All historical data synchronized between servers. Automatic failover when primary server taken offline. Automatic history backfill (resynch) when offline server placed back online. If primary server is offline, its Historian will be backfilled by the backup server when placed online and vice versa. Report and historical trend data requests automatically access highest priority Historian Server

7. Multi-location, multiple computers Physically separated locations provide redundant Historical storage for one another. Physical separation = offsite storage = happy IT people. All data need not be stored on all Historian Servers, limiting disk space requirements for some servers. Reports and historical trends can be generated using data from both plants, even if the WAN connection is unavailable.

8. Multi-location, centralized management (i.e. The Mothership) Historian redundancy at all points in the application. Reports and trends can be generated using data from all plants, even if the WAN connection is unavailable. Local plant data storage is buffered locally during WAN outages. Local plant servers are much less expensive than centralized Servers.

9. How the VTS10 Historian makes this possible

10. Say Hello to the Historian Tag. LogManager has been replaced by the Historian Tag, defining the interface to a database. No limit to the number of Historian Tags that can exist. Primary benefits Load Balancing Synchronization with UTC timestamps Supports custom methods for manual data overrides Support attribute logging Log 2 timestamps per record – time of occurrence and time logged Can generate an alarm if the database connection fails

11. Support for unlimited redundant historians and distributed data logging. No limit to number of distributed Historian Servers in an application. Each data point can be logged to any number of Historian Servers Different data points can be logged to different servers (load sharing.) VTS treats the distributed Historians as one large repository. Historical Storage can be VTS Historian (fastest), SQL, MySQL, SQLite, Oracle and any combination of these.

12. Centralized Historian data access and ease- of-use tools No limit to the number of local plant Historians that can synchronize data with a centralized Historian Each computer can store each data value to one historian, either local or on a separate networked server Reports can be run at the plant level on its local data and on a system- wide level on all SCADA data. All data is available to all computers in the network, regardless of architecture. If one Historian has the data, all computers can access it. Support for industry-standard historian data access: OPC (real-time data) ODBC (real-time and historical data) Web Services (historical data)

13. Reduced resource use and smart design tools ‘Storage limiting’ is set independently for each Historian. Allows long term storage for some variables and short term storage for others. Custom tag types can be defined to store string data and compound tag values in a single record. Dramatically increase a server’s historical data logging speed by logging to multiple local Historians, each with its own hard drive. Historian work is done by a separate core, offloading the primary application core

14. Addressing pitfalls of low bandwidth and unreliable networks Historian data transfer between redundant servers via optimized data packet size. Checksum verification on packets ensure no data loss during synchronization. Supports high-speed synchronization of large amounts of data (log rate of 4,000 values/sec, sync rate of 160,000/sec across WAN) Historical data synchronization between servers treated as a background task (does not interfere with normal operations)

15. Can I upgrade from a previous version of VTS and retain my historical data? The short answer – YES! The long answer is as follows Mostly automated process Single Historian Tag created Legacy data must be copied to each client

16. A couple of examples

17. Gainesville Regional Utilities Multi-locations architecture Redundant, synchronized Historian Servers Combined storage methods VTS Historian SQL Server

18. City of Ocala ‘Mothership’ architecture – 5 systems integrated into one application, central Historian Server Fully redundant data logging architecture

19. Call Us 1 (800) 463-2783 (Toll-free in North America) Write Us info@trihedral.com Visit Our Website www.trihedral.com Visit the VTScada Software Forum www.trihedral.com/forum © Trihedral Engineering Limited 2011 More Information