1. Slide 1

2. © 2012 Invensys. All Rights Reserved. The names, logos, and taglines identifying the products and services of Invensys are proprietary marks of Invensys or its subsidiaries. All third party trademarks and service marks are the proprietary marks of their respective owners. WW HMI SCADA-08 System Platform Best Practices Michael Brost Wonderware System Consultant NA 08/20/12

3. Slide 3 Topics to be Covered Beginning a Project Working as a Team Design Guidance Modeling Sizing Graphics Historians

4. Slide 4 Beginning a Project Now that you have a project to do where to begin… Set up a Development Infrastructure –Enables individual efforts –Enables collaboration and reuse Architecture and Software Installation –Personal Engineering Workstations –Project Server(s) Galaxy Repository Historian Automation Object Servers Workflow Server Information Server Second level text set in Verdana 18pt with 24pt linefeed. –Third level text set in Verdana 16pt with 20pt linefeed. Fourth level text set in Verdana 15pt with 18pt linefeed. –Fifth level text set in Verdana 14pt with 17pt linefeed. Master text first level. This text is set in 18pt Verdana with 24pt linefeed. This text is set in 18pt Verdana with 24pt linefeed. To emphasize a word or phrase, set the text in Verdana Italic as shown in this sentence.

5. Slide 5 Engineering Workstations Project Servers (Operating System Instances) Project Infrastructure EWS 1 EWS 2EWS 3EWS 4 Galaxy Repository AOS RMC AOS Historian Server Information Server Workflow Server

6. Slide 6 Personal Engineering Workstation Operating System –Windows 7 Installation –MS SQL Express or MS SQL Developer –System Platform DVD Install System Platform Development Server (Role Install) –Remove the InTouch Demo Apps if Desired Historian Server Node (Role Install) Optional –Testing of Object history and Tiering of Historians. Applicable DA Servers if needed This provides for a complete standalone development workstation with all capabilities covered by Dev. Studio License.

7. Slide 7 Project Servers Role Based Operating Systems (Recommended) –Can be consolidated to a fewer number of OS’s Physical or Virtual Operating systems –Server OS’s Recommended GR, Historian, WIS, WF –SQL Server Standard Edition x86 Option (32 bit) for System Platform 2012 and earlier x86 0r x64 (32 or 64 bit) beginning with 2012 R2 Role Based Installs simplify the Setup Choices. Wonderware Licensing allows for multiple SQL Server installs. Automation Servers can be Workstation OS. * these are not comprehensive instructions

8. Slide 8 Production Galaxy Repository Create Two Galaxies –Template Galaxy (Undeployed Storage for Templates) –Production Galaxy (Deployed Running System) Security should be enabled on Both. –Each Developer has their Own User ID Unique Checkin/Checkout Default Platform, Engine, Area, Security Group –Avoid the “None” Security model with multiuser access to GR. Use aaPackages to transfer templates. Configure Quality and Status beyond the default settings. Enable outlining as a means of to display results on all graphics Highlights many non-Random errors that may be present

9. Slide 9 Production Galaxy Repository Load core template library into these Galaxies. –Shameless plug for the Base Template Library as a Starting Point Provides for elegant DI Options Allows moving of Objects between Development, Test, and Production with a minimal of Editing. Lots of Cool Model Information –Lists in Objects –MyAreas, MyContainers, MyAnalogFAs, MyDiscreteFAs, Etc. –Area Treeview’s for Alarm Filtering –System Objects Display –Platforms, Engines, Device Integration –Treeview Navigation via InTouch Project Folders Has a Nice InTouch Application Framework

10. Slide 10 Production Galaxy Repository Load core template library into these Galaxies. Setup Non-Package Transferable Galaxy Configuration –Quality and Status –Security Groups –User Security Model Galaxy OS User OS Group –Communications Management –Languages –Script Function Libraries Create a *.CAB file to be placed in the BackupGalaxies Directory C:\Program Files\Archestra\Framework\Bin\BackupGalaxies Use as a basis for new Galaxy Creation

11. Slide 11 Workstation Galaxy Repository Create a Galaxy as a development sandbox. –Base Galaxy on Standard *.CAB for your Organization –Security is optional, but suggested. Use Security to enable read-only access to Real-DAServers for testing. –Create a Unique Development Infrastructure Objects Platform for Local GR Platform(s) for Test AOS(s) if desired. Application Engine(s) For Object Testing –Point to Testing Historian not Production Historian Device Integration Client Object(s) –Point to Test DAServers if available –These Objects Instances should not be routinely transferred to other Galaxies They are specific to their infrastructure Transferring requires editing and hence mistakes. They are rarely application specific, except for names.

12. Slide 12 Engineering Workstations Project Servers (Operating System Instances) Project Infrastructure EWS 1 EWS 2EWS 3EWS 4 Galaxy Repository AOS RMC AOS Historian Server Information Server Workflow Server Template Galaxy Standard Templates Project Templates Production Galaxy Platforms Engines Dedicated DI Clients Development Galaxy Platforms Engines Dedicated DI Clients

13. Slide 13 Sizing Guidelines Operating System Sizing GR –Windows 2008 R2, 4 Cores, 4-8GB Memory –Recommended to be Virtualized –Only way to recover a GR without a Required Deployment AOS –Windows 7, 4 Cores, 4GB Memory –Vitualize Larger Hardware into Blocks this Size –Improves Deployment Speed –Failover Performance –Upgrade with Minimum Downtime (Following Section) –25,000 IO Per Standard AOS or Redundant AOS Pair (YMMV) –Ideally DA Servers are Local

14. Slide 14 Sizing Guidelines Operating System Sizing InTouch Workstation –Windows 7, Dual Core, 4GB Memory –High clock speed better than more cores –Fast Disks or Solid State (Loading windows from disk) InTouch RDS Server –Windows 2008 R2 –Lots of Cores (16), Lots of Memory (48GB) –Solid State Disks –25 - 75 Sessions per Server (YMMV)

15. Slide 15 Galaxy Design Guidelines (Estimates?) Platforms Multiple AOS Platforms reduce deployment times Application Engines (Galaxy Work Horse) 1 Active Engine / Core / 1-2 GB 5-10,000 IO / Engine 2,000 Objects / Engine Standard Engines can Handle a Heavier Load than Redundant Engines View Engines Can host multiple InTouch App Instances Can serve as an Active Engine in Runtime –Template for Configuration Settings –Holder of ArchestrA Graphics as Windows Multiple View Engines Can be Used on same Platform (Have a good reason for THIS)

16. Slide 16 Galaxy Design Guidelines (Estimates?) Areas Provides for Object Distribution across Engines Hierarchical Model –Alarming and Events –Historical Data (If Enabled to 1 st Tier Historian) Areas are Sisters in Execution Not Hierarchical Must have Multiple Areas to support Multiple Engines Rollup of Alarm Counts / Enable / Silence / Disable Limit of 500 Objects / Area is a good rule of thumb

17. Slide 17 Galaxy Infrastructure Create Templates for Standards or Where Future Deviations Exist –Lockable Read Only Attributes Will not be Dumped via Galaxy Dump Propagation will be guaranteed Slightly better performance –Writable Attributes needing Initialization in Configuration or Runtime Locking cannot be used Utilize an OnStartup script to set the Values –Script can be locked to ensure propagation of changes in IDE –Attribute values will remain writable at runtime –Use Read-only Security for IDE only settings. (enforced even with “None” Model) –Protects against Upload Runtime Changes overwriting initial values

18. Slide 18 Organize your Templates Create a Template Storage Galaxy –Maintains current Templates –Distribute via Packages –Control distribution of updates –Should always have Security Enabled Levels in hierarchy dictate Ownership within Team/Organization Very Few Instances should exist in this Galaxy –Necessary for placing template Graphics on InTouch Windows

19. Slide 19 Base Template Library Owned Template Organization/User Owned Template Water Filter Project Owned Template Water Filter Template

20. Slide 20 Multiple Developers in one Galaxy IDE Local GR IDE Local GR IDE Local GR IDE Local GR Production GR Production Galaxy Template Galaxy Each Development Workstation has a Local Development and Test Galaxy

21. Slide 21 Scaling out Production w/Galaxy Load Good Tool for scaling out the Production Galaxy Allows Speadsheet definition of Instances Can also Manipulate Existing Instances Change Areas Attribute Values Only Attributes to be Changed are Required Tagname is the Key (Always Required) Tagname and SecurityGroup (Required for new Instances) Format is Simple Even the Cancel Button works Can Create “Templates” of Non-Templateable Objects DI Networks and Devices Areas and Contained Objects Engine Layouts for Platforms

22. Slide 22 Galaxy Load to create instances

23. Slide 23 Device Integration Objects Four types of Device Integration objects are in the Galaxy Toolbox Di Client Objects Connect to externally installed and configured DA Servers and Applications Di Network Objects Contain DA Servers in the Runtime Package which is deployed to the Target Platform Di Device Objects Configure the Di Network device hierarchy and serve as Di Client objects to the component in the hierarchy of devices on this Network. Redundant Di Objects Choose between two DI Client objects as a provider of Device Items to Application Objects S li d e 2323

24. Slide 24 Redundancy Treat Redundancy as an Insurance Policy Understand what it covers and what it does not. Device Communication –Selects Between Two Dedicated Communication Paths to a Device –Failover Less Than 5 Seconds Application Engine Redundancy –Preserves the aaEngine as a Service –Executes a state-full restart of the Engine Service on another Platform –Failover Less Than 1 Minute Operating System Redundancy –Managed by Hyper-V, V Motion, or Hardware –GR, WIS, RDS, Historian, Workflow –Executes a state-full restart of the OS –Failover Less Than 10 Minutes (Typically)

25. Slide 25 Reactor04 RDIO Reactor03 RDIO Redundancy AOS RMC AOS PLC01PLC02 PLC01 DDIO PLC02 DDIO DAServer Reactor02 RDIO Reactor01 RDIO

26. Slide 26 Historian Historian Servers Two Main Roles in a System Operational Historian (Short Term Trending, Reporting, Statistics) Business Historian (Long Term Storage, Process Analysis, Advanced Reporting) Same Historian Instance for Both Roles Historian Placed in a DMZ Tiered Historians offer a Better Solution Local Operational Historian (25K Tags, 7 Days) $2.5K Enterprise Business Historian (Part of System Platform Bundle) No Need for a DMZ Single Outgoing TCP Port on SCADA Firewall Supports Domain Isolation Security Model (No Shared Credentials) Push of Configuration and Data from SCADA to Business LAN Enhancements in 2012 R2 –Replicated Data provided via DAServer on Business Historian –Dual Local and Business Historians

27. Slide 27 SCADA Domain Business Domain Tiered Historian Architecture Corporate Network Enterprise “Tier 2” Historian Client Application Server InTouchI/O Control Network Local/Std “Tier 1” Historian Historian Client Historian Client Open Outbound Replication (single TCP port)

28. Slide 28 Business Historian as a R/O Real-time DAServer 2012 R2 Release Corporate Network Enterprise “Tier 2” Historian Client Application Server InTouch Local “Tier 1” Historian Historian Client Open Outbound Replication (single TCP port) DAServer RDS/WIS Server DMZ Required Customers Corporate Engineering Advanced Alarming

29. Slide 29 Tiered Historians For WAN Data Collection MDAS and Application Engines (Soon to be Classic Storage) Multiple remote AppEngines WILL cause serious Fragmentation of History Blocks. MDAS is DCOM based and not firewall friendly. Bad Data values are inserted into History. AppEngine to a single Historian Tier-1 to Tier-2 (New Storage System) Does not create Stream Files in History Blocks Utilizes WCF (Winsock TCP) Tier-2 Retrieval is superior to Tier-1 3x Retrieval Performance Fidelity can be changed Target Multiple Historians 2012 R2 all App Engines use the new Storage Subsystem Will deliver to Partner Historians (Great for DR sites)

30. Slide 30 B 2 Dual Partner Historians System Platform 2012 R2 Wonderware Historian Control System Application Server Historian Client 1 A.Client retrieves “partner” name B.On a failure, automatically switches A 1.Engine retrieves “partner” name 2.Sends same data to “partner” with independent store-forward channels 3.Can be Geographically Separated 4.Additional Tiers are Possible Limitations No “self healing” of drive, history blocks, etc. Updates/inserts (SQL, CSV) must be repeated Client won’t switch on “store-forward” H1H2

31. Slide 31 SCADA Domain Business Domain 2012 R2 Redundant Tiered Historian Architecture Corporate Network Enterprise “Tier 2” Historian Client Application Server InTouchI/O Control Network Redundant Local/Std “Tier 1” Historian Historian Client Historian Client Open Outbound Replication (single TCP port)

32. Slide 32 System Upgrades with Minimal Downtime OPS 1 OPS 2OPS 3EWS Galaxy Repository AOS RMC AOS SP V3.1SP 2012 Install New Version on GRInstall New Version on EWSConnect IDE to Galaxy and MigrateInstall Replacement AOS Pair AOS RMC AOS Deploy Duplicate Infrastructure ObjectsMove App Objects to New PlatformsNew AOS are Now Ready to Host ObjectsUpgrade OPS WorkstationsUpgrade Original AOS Pair

33. Slide 33 Causes of ArchestrA Graphic Performance Issues Retrieve Definition Render Bind Data Continuous Updates Close Will be grey if not relevant. S li d e 3333 Call-Up Time Graphic Call-up Time Static CPU Load Memory Utilization RetrieveRenderBindContinuousClose

34. Slide 34 Gradient Usage The definition of gradients are the colors and the type of gradients. All of the individual colors are calculated at runtime when initially rendered and any time an animation changes the gradient. When large numbers of graphic elements (1000’s) using gradients are used the impact can be severe. This information consumes more memory than a solid fill. Be careful of a larger number of small graphic elements using gradients. The effect may be minimal visually but severe in terms of performance. Transparencies have a similar performance impact. S li d e 3434 RetrieveRenderBindContinuousClose

35. Slide 35 Gradient Usage Example Same Embedded Symbol (just resized) Same Detail Same Calculations Same Cost Different Visual Value S li d e 3535

36. Slide 36 Custom Property Density Custom Properties have been greatly optimized in InTouch 2012 which has resulted a much lower performance impact. Some customers have ended up with 20,000 plus custom properties on a symbol. Typically an impact of embedding many symbols at many levels. Should consider necessity of the variables and consider if they should reside server side. Is it needed for graphic presentation? Is the value specific to only this workstation? S li d e 3636 RetrieveRenderBindContinuousClose

37. Slide 37 Multi-Variable Expressions Each variable must be subscribed, bound and published individually. Can the calculation be done server side? Is the value specific to this specific workstation? Expressions are ad-hoc scripts and require execution. The AppEngine is better suited to executing volumes of scripts and should be used to handle load where possible. S li d e 3737 RetrieveRenderBindContinuousClose

38. Slide 38 Script Utilization ArchestrA Graphics are extremely flexible in their ability to execute scripts. (On Show, While Showing, On Close, Data Change, Condition) Carefully plan the usage of scripts that will cyclically execute. If you are setting a script to run every 50ms? Why? Is every execution needed? Is the same result be calculated over and over? How many scripts are on the symbol? How many of this symbol will be used? Can the script be server side? S li d e 3838 RetrieveRenderBindContinuousClose

39. Slide 39 Element Grouping When using the Grouping mechanism in graphics there is an optimization done for groups with no animation. The group is handled as an image. S li d e 3939 RetrieveRenderBindContinuousClose The Tank on the right opens in half the time with half the static CPU load of the tank on the right.

40. Slide 40 ArchestrA Graphics in InTouch Avoid Assembling ArchestrA Graphics in the InTouch Window Create an ArchestrA Graphics Toolset For InTouch “Windows” For Each InTouch Window Create an ArchestrA Symbol For It –Assemble the Graphics in the Symbol for the Window –It is now reusable across InTouch Applications and WIS –You will be Better Prepared for the ArchestrA Window Object Object Template Graphics must be Assembled in an Object –Candidate Objects for this organization –Area Objects –View Engine Objects Once Laid out the InTouch app does not need to be opened in WindowMaker InTouch View Application Instances Provide a DI Gateway to the InTouch Tag Dictionary InTouch: is the Relative name from ArchestrA Graphics Galaxy: is the Relative name from InTouch

41. © 2012 Invensys. All Rights Reserved. The names, logos, and taglines identifying the products and services of Invensys are proprietary marks of Invensys or its subsidiaries. All third party trademarks and service marks are the proprietary marks of their respective owners. Thank you! Questions?