Transcript Tech Symposium Template

Slide 1
WW HMI SCADA-08
System Platform Best Practices
Michael Brost
Wonderware System Consultant NA
08/20/12
© 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.
Topics to be Covered
• Beginning a Project
• Working as a Team
• Design Guidance
• Modeling
• Sizing
• Graphics
• Historians
Slide 3
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
Slide 4
Project Infrastructure
Project Servers (Operating System Instances)
RMC
AOS
Galaxy
Repository
Historian Information Workflow
Server
Server
Server
EWS 1
Engineering Workstations
Slide 5
AOS
EWS 2
EWS 3
EWS 4
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.
Slide 6
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
Slide 7
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
Slide 8
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
Slide 9
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
Slide 10
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.
Slide 11
Project Infrastructure
Project Servers (Operating System Instances)
Template Galaxy
Standard Templates
Project Templates
Production Galaxy
Platforms
Engines
Galaxy
Historian Information Workflow
Dedicated DI Clients
Repository
Server
Server
Server
RMC
AOS
AOS
Development Galaxy
Platforms
Engines
Dedicated DI Clients
EWS 1
Engineering Workstations
Slide 12
EWS 2
EWS 3
EWS 4
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
Slide 13
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)
Slide 14
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)
Slide 15
Galaxy Design Guidelines (Estimates?)
• Areas
• Provides for Object Distribution across Engines
• Hierarchical Model
– Alarming and Events
– Historical Data (If Enabled to 1st 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
Slide 16
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
Slide 17
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
Slide 18
Base Template Library
Organization/User
Owned
Owned
Template
Water
Filter
Project
Owned
Template
Template
Water Filter Template
Slide 19
Multiple Developers in one Galaxy
• Production Galaxy
• Template Galaxy
Production
GR
Local IDE
GR
Local IDE
GR
Local IDE
GR
Local IDE
GR
Each Development Workstation has a Local Development and Test Galaxy
Slide 20
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
Slide 21
Galaxy Load to create instances
Slide 22
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
•
Slide 23
S
Choose between two DI Client objects as a provider of Device Items to Application
Objects
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)
Slide 24
Redundancy
RMC
AOS
AOS
Reactor01
RDIO
Reactor02
RDIO
Reactor03
Reactor04RDIO
RDIO
PLC01 DDIO
PLC01 DDIO
PLC02 DDIO
PLC02 DDIO
DAServer
DAServer
PLC01
Slide 25
PLC02
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
Slide 26
Tiered Historian Architecture
Business Domain
Enterprise
“Tier 2”
Historian
Historian
Client
Historian
Client
Corporate Network
Open Outbound
Replication (single TCP port)
SCADA Domain
Local/Std
“Tier 1”
Historian
Historian
Client
I/O
Slide 27
InTouch
Control Network
Application
Server
Business Historian as a R/O Real-time
DAServer 2012 R2 Release
Customers
InTouch
Corporate
Engineering
Historian
Client
RDS/WIS
Server
Application
Server
DAServer
Advanced
Alarming
Enterprise “Tier 2”
Historian
Corporate Network
Open Outbound
Replication (single TCP port)
DMZ Required
Local “Tier 1”
Historian
Slide 28
Historian
Client
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)
Slide 29
Dual Partner Historians
System Platform 2012 R2
Historian
Client
B
A. Client retrieves “partner” name
B. On a failure, automatically switches
A
H1
H2
Wonderware
Historian
1
Application
Server
Control System
Slide 30
2
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”
2012 R2 Redundant Tiered Historian Architecture
Business Domain
Enterprise
“Tier 2”
Historian
Historian
Client
Historian
Client
Corporate Network
Open Outbound
Replication (single TCP port)
SCADA Domain
Redundant
Local/Std
“Tier 1”
Historian
Historian
Client
I/O
Slide 31
InTouch
Control Network
Application
Server
System Upgrades with Minimal Downtime
New
Deploy
Move
Connect
AOS
Install
Install
Upgrade
Upgrade
Install
App
Duplicate
areIDE
Replacement
New
Objects
Now
New
OPS
to
Original
Version
Infrastructure
Ready
Galaxy
Version
to
Workstations
New
AOS
to
AOS
on
and
on
Host
Platforms
EWS
Pair
GR
Migrate
Pair
Objects
Objects
RMC
AOS
AOS
RMC
AOS
AOS
Galaxy
Repository
OPS 1
SP V3.1
Slide 32
OPS 2
SP 2012
OPS 3
EWS
Causes of ArchestrA Graphic
Performance Issues
Retrieve Definition
Graphic Call-up Time
Render
Static CPU Load
Bind Data
Memory Utilization
Continuous Updates
Close
Will be grey if not relevant.
Call-Up Time
Retrieve
Slide 33
S
Render
Bind
Continuous
Close
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.
Retrieve
Slide 34
S
Render
Bind
Continuous
Close
Gradient Usage Example
• Same Embedded
Symbol (just resized)
• Same Detail
• Same Calculations
• Same Cost
• Different Visual Value
Slide 35
S
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?
Retrieve
Slide 36
S
Render
Bind
Continuous
Close
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.
Retrieve
Slide 37
S
Render
Bind
Continuous
Close
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?
Retrieve
Slide 38
S
Render
Bind
Continuous
Close
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.
The Tank on the right opens
in half the time with half the
static CPU load of the tank
on the right.
Retrieve
Slide 39
S
Render
Bind
Continuous
Close
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
Slide 40
Thank you!
Questions?
© 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.