System Platform Best Practice Guide 2014 R2

Transcription

1 System Platform Best Practice Guide 2014 R2

2 Contents Introduction... 2 Hardware and Architectural Considerations... 3 Virtual Environments... 5 Availability Environments... 6 InTouch application... 8 Redundancy Model View Deployment Performance and Metrics General Galaxy Time Master Communications Management Toolbox layout System Platform Engine ViewEngine Area Device Integration DI Objects RedundantDIObject DA Server Application Objects Containment Derivation Naming Convention Individual Object configuration Page 1 of 28

3 Introduction The document has been provided subject to the following caveats: The document is for advisory purposes only and does not guarantee system performance. As such, there is no acceptance of risk or liability on behalf of SolutionsPT. This engagement does not constitute that of a design authority and any comments made by SolutionsPT within this document are not those of Schneider-Electric and are therefore not necessarily supported or sponsored by Schneider-Electric. It is assumed that the reader of this document is familiar with the working environment of Microsoft Operating Systems and the relevant Wonderware product suites. This document should be considered as always in development and is not a complete guide; as such it is subject to change. This document covers Wonderware System Platform 2014 R2. Page 2 of 28

4 Hardware and Architectural Considerations It is best practice to have a separate machine for each major function, e.g. a machine for a GRNode, a machine for the Historian server. However, dependent upon hardware specification and testing, system functions can be combined onto one or more machines. If you are in any doubt, please refer to your Wonderware Account Manager. NOTE: do not combine Wonderware software on the same machine as a Domain Controller. GRNode The Galaxy Repository (GRNode) can run on a client Operating System only in a single node scenario. Set Microsoft SQL Server to CPU other than 0 (which is the default). Windows Server 2012 R2, 4 Cores, 4-8GB Memory, medium and large. Recommended to be Virtualized Only way to recover a GR without a Required Deployment HD 150GB Object Server node Be aware that an Engine is a process and can only span a single core; more engines mean more cores are utilized. A good target max is a Quad core environment. 1GB per Core is a good rule of thumb. Windows Server 2012 or 2012 R2, 4 Cores, 4GB Memory Virtualize Larger Hardware into Blocks this Size Improves Deployment Speed Failover Performance Upgrade with Minimum Downtime (Following Section) 80,000 IO Per Standard AOS or Redundant AOS Pair (YMMV) Ideally DA Servers are Local HD 100 GB InTouch Runtime node Be aware that InTouch runs in 32 bit mode, but can utilize 4GB on a 64 bit OS. The recommended Client OS is Windows 8.1 Professional, Enterprise (32/64-bit). A Dual Core is a preferred target host. High clock speed better than more cores Fast Disks or Solid State (Loading windows from disk) HD 100 GB Hardware choices that can provide better results for Retrieve and Binding in ArchestrA Graphics are: o Fast CPU Clocks faster dual core is better than slower quad core. o Have 3 or 4GB available for the InTouch application. o Fast Hard Drive solid state drives Page 3 of 28

5 o Fast GPU Use the Windows Experience Index and look at Graphics and Gaming Graphics scores. InTouch RDS Server Every system is different but as a general rule we would expect 1 CPU core and a minimum of 1GB of RAM per InTouch session that was going to run. This is always dependent upon size and complexity of the application. Windows 2012 R2 Lots of Cores (16), Lots of Memory (32GB) Solid State Disks Sessions per Server (YMMV) Every connection uses around 200 to 300 KB.sec cap desktop fidelity HD 100 GB Use the core allocation for view sessions 2GB as a standard recommendation, or have 3 or 4GB available for each View session if the application is resource intensive. Historian Historian is not support on cluster hardware. Do not use the Historian server as a domain controller, mail server or an Internet server. If you run Historian on a virtual server, the Historian must have adequate CPU, network, memory and disk I/O resources at all times. Overloading the virtual server could lead to unpredictable behaviour. HD 250 GB disk Cores 4 cores 4 GB of RAM. Windows Server 2012 R2. Solid state Disk for Databases and History blocks o The History blocks should only consist of the most recent few months on the solid state disk, anything older should be moved to an alternative storage location on slower, larger disks, preferably SCSI technology. Page 4 of 28

6 Virtual Environments Consider virtualization with high spec machines, i.e. better to have 4 x 4 core virtual machines rather than a 16 core physical server. The system may want redundancy with two physical server hosts so that if the physical server (hosting several virtual machines) has an issue, they can be recovered/fail over to a secondary physical server. This all depends on the criticality of the system. It may be enough to manage the availability of the physical host server, e.g. UPS, Stratus, etc. Virtualization guidelines Storage 1 spindle per VM Historian consider SSD for retrieval Migration networks 1 GB/sec or higher Measure the traffic to disk and size accordingly. Recommendation disk speed 80 Input/Output Operations Per Second (IOPS) minimum per VM. Mechanical drive 100 IOPS, SSD 400 to IOPS HA VMWARE or Hyper V Disaster recovery (DR) preferred technology - SIOS and Hyper V - reason is that is fully automated Virtualization general rules Do not use snapshots in production environments, use backup software that does not use VSS. If you do use snapshots determine what it means that a VM does not operate during that time. Pre-production snapshots are desirable. For development iterations. Do not use dynamically expanding disks in production environments, used fixed. Specify the resources as minimum. Treat every piece of functionality within ArchestrA as a separate VM. Example ask IT if they would combine a domain controller with a mail server. Page 5 of 28

7 Availability Environments Customer Requirements Data Loss (Monthly) Server Offline Availability Cost Bandwidth Needed for Synchronization Simplex Non-Virtualized, Virtualized 1-6 Hrs Un-protected 99 $ 0 A2 Application redundancy, AOS and Hist. Non-Virtualized, Virtualized 45 Sec Un-Protected GR or TS Warm Start 99.5 $$ 1-10 Mb/s Virtualized HA + Application redundancy 45 sec-2 min Protected Warm Start Cold Start (3 servers) $$$ Mb/s Virtualized DR Non Automated Replication SW 7-15 min Dual site protection Cold Start $$ 2 10 Mb/s Virtualized HA/DR Automated Sios. 45 sec-15 min Protected Cold Start Warm Start $$$ Mb/s Virtualized FT Stratus Everun Sub seconds Protected Hot Start $$$$ 800 Mb/s HW Redundancy Sub seconds Protected Hot Start $$$$$ 0 Cold Start = a start of a VM from disk to be operational loosing memory state. Warm Start = A Controlled failover preserving state, redundant engines, Vmotion (VMWARE), Live Migration (Hyper V). Secondary node is in standby. Hot Start = Synchronous lock step second VM or HW. Secondary node is running. Page 6 of 28

8 Page 7 of 28

9 InTouch application Check the Graphics section within the document. Graphics can cause performance issues. (See here). You should check each window to see the loading time and highlight poor performing windows. ArchestrA Graphics have a lifecycle, at each stage of the life cycle there are different variables that can affect the performance. Below is a simplified overview on the main contributors to the time consumption when showing a graphic Retrieve Definition: Size and complexity of the ArchestrA Graphics Binding Data: Number of custom properties and references Use a clever organization of the information: 1 integer custom property instead of 16 Boolean custom properties when designing a symbol that will be used across all the graphics of your application (icons, alarm states) Try to avoid redundant information by reusing Custom Properties for the embedded symbols. Clever use of Private/Public Use of Owning Object/SetCustomProperty/ShowGraphic Hardware choices that can provide better results for Retrieve and Binding are: o Fast CPU Clocks faster dual core is better than slower quad core. o Have 3 or 4GB available for each View session o Fast Hard Drive solid state drives o Fast GPU Use the Windows Experience Index and look at Graphics and Gaming Graphics scores. Rendering Time: Total number of simple and complex graphic elements, runtime graphic effects The rendering time is impacted by the high number of primitive invokes: each single line, circle, textbox we are drawing has a cost. Extremely high definition of small details can impact the rendering performance Reusing multiple times an extremely hi detailed small icon symbol can reduce the rendering performance of the entire application Gradients, transparencies, graphical effects that need runtime calculation can impact rendering performance (CPU vs GPU: GDI+ vs GDI) o Central Processing Unit vs Graphics Processing Unit: The GPU enhances the capabilities of the CPU o The latest version of the Graphics Device Interface is an improvement on GDI such as gradient brushes, alpha blending, and more image format support Be careful of a larger number of small graphic elements using gradients. The effect may be minimal visually but severe in terms of performance. Resizing graphics does not reduce the time taken to load, as the system will still have the same details, same calculations, same cost, but different visual value. Sometimes it may be worth showing a PNG image instead of a tiny graphic. Reduce background detail as much as possible HMI Handbook/efficient HMI advised on clean background. The performance gain can be huge. Having needles on a gauge background (looking like a rev counter) is heavy in performance compared to having needles moving on a Page 8 of 28

10 grey background. A test with 134 instances on 1 window showed a difference of 80% CPU usage for the one with the gauge background, and 3% CPU usage for needles on a grey background. For example: Awaiting Data: Engine scan cycle, I/O speed, Communication strategy This section is now waiting for new values for the data. ActiveAll reduces the call up time of the graphic Expression Evaluation: Total number, complexity, code efficiency Multi-variable expressions each variable must be subscribed, bound and published individually. Therefore expressions are ad-hoc scripts that require execution. The AppEngine is better suited to executing volumes of scripts and should handle load where possible. Keep in mind that a reference is faster than an expression at runtime. i.e. True is faster to load in runtime rather than 1==1. Also look at any animations or conditions that can be grouped, work with the logic that 10 is better than 100 calculations. So if multiple animations can work from the same condition or reference then utilize this. Remember, embedding has a cost in performance, so there can be a negative effect of embedding a graphic that s just a line or a very small addition, it may be worth drawing that element within the main graphic to reduce the amount of embedding. DATACHANGE scripts are always preferred to WHILE running scripts as expressions are only evaluated upon data change, not always. Delta Rendering: Number of data changes + total number of simple and complex graphic elements, runtime effects etc. Further references are in Tech Notes: 628 Advanced Communication Management for Application Server 644 Improving Application Performance with ArchestrA Graphics High Performance HMI Handbook. Page 9 of 28

11 Other questions for general settings for Window Viewer: Has the customer set Home windows? These can be used rather than scripting an application start up script. Has the customer set priority windows and caching? This can assist with the heavier windows to improve loading times. See below of where the settings are within InTouch: The total amount of memory accessible to WindowViewer has been extended to the maximums by default. 2 GB on 32 bit OS; 4 GB on 64 bit OS The memory cache will remove oldest windows from the cache to make room for new windows being opened. First in/first out and time based aging Windows that are a high priority for fast access can be designated which will result in them being always considered recent. Page 10 of 28

12 Redundancy Redundancy is a large topic area to cover. Within this document section, redundancy is covered with regards to Application Engine redundancy. Each production system node hosting a redundancy enabled AppEngine must have a minimum of two network card per machine. The first machine is for the supervisory network and the second is for the Redundancy Message Channel (RMC). The RMC network is dedicated for redundancy monitoring and data synchronization between redundant AppEngine pairs. When configuring the networks, you must ensure that the Primary supervisory network is the first in the Network Binding Order (see advanced network settings). Please note that it s also recommended to disable IPV6 as it s not supported directly by Wonderware software. The RMC Network must be configured for a Static IP address. Wonderware have discovered issues with Application Server redundancy and the RMC when TCP Offload Engine (TOE) is enabled. See section 4.2 Engine for engine level redundancy recommendations. See section 5.2 RedundantDIObject for redundancy at a data source level. Page 11 of 28

13 Model View To build up the area model from scratch we d recommend that two areas are created first, one called ControlSystem; this area will be where all platforms and engines are placed. This allows the ability to not display alarms from these within InTouch. The next area would be named after the plant; this will be the main area that will contain all other areas of the plant. This allows the ability to query all alarms from the plant without having to list every area. Once the plant area has been created, each section of the plant is created e.g. Intake, Production & Discharge. The next step would be to split the above areas down into their smaller areas, for example Production has multiple lines. You can have as many areas as you would like however you must bear in mind maintenance of the system will be harder if you have the plant split down into thousands of areas. As you can see in the image below, using a good naming convention allows the ability to review data based either on the specific area name or their location. Page 12 of 28

14 The alarm grouping on the system is done based on the area model which you have defined. When querying the alarms for an area, if additional areas exist under the area as child areas, these alarms are also returned. In the example Model View image outlined above, you could either query the alarms on line 1, 2 or 3 however if you wanted to retrieve all alarms for all lines then you d simply query the alarms from Production. Deployment To deploy a Galaxy you can cascade deploy from the Galaxy object level, this is fine for small Galaxies. With large systems it s advised to deploy from the Platform level, with cascade deployment unchecked. This allows each level to be deployed first without causing any loading or timeout issues. Engines must be deployed on Platforms. There are two types of engines that exist: $AppEngine (Application Engine) these are used to execute objects. An AppEngine can be configured as a static engine or a redundant engine. $ViewEngine these are used to execute the InTouch application. Application engines can run DI objects, these DI objects should only be hosted on static application engines (i.e. non redundant). The AppEngines can execute normal/application objects, but these bust be hosted by an Area. In a basic client-server setup, the server machines will typically run a Platform and at least one AppEngine. The client machines will have a Platform and a ViewEngine. In a stand-alone setup, there will be a Platform, with at least one AppEngine and a ViewEngine. It s also recommended that at least a top level Systems area be deployed to the GRNode. This area should contain all the systems objects in the Model View (Platforms and Engines); this requires the GRNode to have an AppEngine. More information about the Model view can be found in the relevant section. Page 13 of 28

15 Ensure that the security model setup in section 3.1 has been fully tested prior to full deployment of the system. Page 14 of 28

16 Performance and Metrics Some Object Viewer attributes that can be viewed to review performance and scaling. General Platform Metrics CPU Loading: CPUload, CPULoadAvg, CPULoadMin, CPULoadMax. Memory: RAM, RAMAvailableAvg. Disk IO: DiskBytesReadAvg[], DiskBytesWritesAvg[], DiskReadsAvg[], DiskWritesAVG[]. Advanced Engine Metrics Application Engine Metrics: Scheduler.ScanPeriod, Scheduler.TimeIdleAvg (Should be 50% minimum of Scan Period), Scheduler.TimeIdleMax, Scheduler.TimeIdleMin, Scheduler.ExecutionTimeAvg. CPU Loading: ProcessCPULoad, Scheduler.ScanOverrunsCnt (not always a terrible thing), Scheduler.ScanOverrunsConsecCnt (This one is much more serious). Engine Scaling: Engine.AsyncScriptsWaitingCnt, Engine.EngineAlarmRate (The number of alarms raised on this object during the prior scan by all objects running on this object), CheckpointPeriodAvg. Page 15 of 28

17 General Galaxy Time Master Some of Application Server functions like scripting, alarming, and historising depend on all member computers of a Galaxy synchronized to the same time. A time master is a Network Time Protocol Server that provides a time that other nodes on your network can synchronise with. The time master can be a non-archestra node within the Galaxy. The ArchestrA nodes in the Galaxy periodically synchronise their clocks to the time master. It s recommended to time synchronise to the Historian server machine if there is one. This can be configured within the IDE under Galaxy > Configure > Time Master. Communications Management If Advanced Communication Management is enabled, the system will allow the Galaxy objects to be activated on demand (Advise On Active premise). The scan group for DI objects must be configured to ActiveOnDemand to take advantage of this setting. Toolbox layout The template toolbox is used for managing your templates, using these allow you to organise the templates into common folders (toolsets) so it s easier to navigate to the template you require. It is recommended that you prefix the toolsets with a number so they stay in the correct order, base templates being the highest so prefixed with a zero (0). We also recommend that the base templates supplied with the software are also put into their own toolset marked as 99. Read Only or hide the folder from the users view. Page 16 of 28

18 System Platform A Platform represents instances of Operating Systems. If the History store forward directory is changed from the blank default, this directory must be excluded from the Anti-Virus software, if applicable. InTouch alarm provider Enable the InTouch alarm provider to set the Platform as an alarm provider for the system. Generally the Historian machine could be used as the InTouch alarm provider. The reason being is that the Historian machine is usually managed for its availability (i.e. minimal down time). Redundancy To configure redundancy for the platform, the Redundancy Message Channel IP address must be configured in the platforms that will host the redundant pair. The IP address registered should be the IP of the local RMC adapter on the machine. Message Exchange The Message timeout setting is the number of milliseconds for a response message for cross-engine communications. The default setting is 30,000ms. It is recommended that this setting is increased on the GRNode to avoid engine communication issues (AppEngine failing to respond within the timeframe therefore causing a communication error) during the deployment of large galaxies. The setting could be set up to 300,000ms for large galaxies. The NMX Heartbeat period is the frequency in milliseconds at which heartbeats are sent to other Platforms. The default value is 2,000ms and no tuning is required for this setting. If Platform X is subscribed to data on an engine deployed Platform Y, the heartbeats will be sent by Platform T to Platform X. Page 17 of 28

19 The Consecutive number of missed NMX heartbeats allowed has a default value of 3, for medium and large systems this value can be increased to around 6. This is the number of consecutive heartbeats that are allowed to be missed from a platform before a platform communication error is generated for that Platform. Engine Engines are processes; they will not span a single core. Multiple engines will leverage multiple cores. A good rule of thumb is 1GB per Core for the machine. A good working target would be 1 Active Engine and 1 Standby Engine per Core. 2 Active Engine / Core / 1-2 GB 10-20,000 IO / Engine 5,000 Objects / Engine Standard Engines can Handle a Heavier Load than Redundant Engines substract 25% for redundant engines A redundant Engine should failover at a 1 minute target, however specific tuning can take place to do this faster or slower. See the Engine Failure Timeout for more details. General Tab Ensure the Scan period is set to a prime number; this will prevent multiple engines running over at the exact same time. Each engine should have a different prime number Scan period. Though the chance of this happening is very low given that engines will be triggered one after another on a deployment. History The engine can be configured to store data to a Historian by checking the Enable storage to historian checkbox. History Connection Note that if the customer changes the TCP port from the default value of then the TCP port must be changed in the Historian Server, as this is the TCP port on the Historian Server to which the history data will be sent. History Bandwidth optimisation The engine can be configured to compress the history data. To do this the Enable compression checkbox must be ticked. If this is enabled the history data is compressed before it is sent to the Historian over the network. This can be used to reduce network usage, however enabling this will increase the CPU load. Therefore if this setting is enabled, the CPU load should be monitored. The Checkpoint Period attribute should be set to 30,000+ms and should not be left at 0. Small systems could get away with 0ms for the value. This essentially means that the engine will try to create a checkpoint file on every scan of the engine. For systems with around 20K I/O the recommended value Page 18 of 28

20 is at least 20,000ms and for systems with 40K + I/O then the value should be 60,000ms. Setting this value too low could result in high resource usage, and corruption of the checkpoint files. Setting the value to high means that if both partners fail, checkpointed data may not be current. If the Checkpoint directory location is anything other than default (i.e. blank), then this folder must be excluded from the Anti-Virus scans. The Engine Failure Timeout setting is used to determine how long that engine has to inform the Bootstrap that it is executing. If the engine does not signal the attribute for 3 consecutive timeouts, the Engine is determined to be in trouble and the redundant partner takes over. The recommended value for this setting is 20,000ms. Setting this attribute too low causes the redundant partner to overreact when CPU usage is high. Setting the value too high can delay notifications that the Engine is in trouble since the Bootstrap considers the Engine healthy until the timeout expires. The Engine failure timeout is the amount of time, in milliseconds, that the engine can run without notifying the bootstrap of its health. After this time elapses, the EngineFailureAlarm attribute is set TRUE in the WinPlatform object. Be sure that you specify a time long enough to accommodate the completion of any engine-related actions that might prevent or delay the bootstrap notification (for example, cascade deployment of objects with a large number of scripts). Internally, the system will triple the value that you specify for this attribute. Redundancy Tab Enabling redundancy on an engine is a simple task of checking an Enable redundancy box in the Redundancy tab of the engine. The Hosting Platform for this engine must be configured for redundancy by configuring the Message Channel IP address. The recommendation for the Forced failover timeout can vary across systems. A Small system (Up to 3K I/O) the recommendation is about 30,000ms. 45,000ms is advised for over 3K I/O and 240,000ms for around 40K I/O. 300,000ms has been recommended for a very large system. If this setting is too small, forced failover will not succeed. If the setting is set too large, failure will not be detected in a timely manner. This setting should be tested and tuned to the system. The default value for the Standby/Active engine heartbeat period is 1000ms. This setting may be increased to avoid false failovers. The Maximum consecutive heartbeats missed from Active engine can vary across different scale systems. A small system could have a value of 5, a medium large system being between 10 and 30 and for a very large system the recommendation is around 60. The same recommended values can be used for the Maximum consecutive heartbeats missed from Standby engine. Setting this value too low produces false failovers, whereas setting the value too high results in slow detection of a required failover. The Maximum time to maintain good quality after failure setting is default to 15,000ms, this value is recommended for a small system and can be increased to 120,000ms for medium to large systems, and for very large systems the value can be increased to around 150,000ms. The Maximum time to discover partner is the maximum time period, in milliseconds, allowed for the connection to the failover partner to be established before the failover partner state is set to Page 19 of 28

21 unknown. The default value for this is 15,000ms. There are no set recommendations for this setting and it does not need to be tuned. R/W Tab The Number of read/write interrupts as default the value is 5. This is the number of times read/write operation occurs during the object execution phase in each engine scan cycle. The maximum number is 256. The Enable standard interrupt can be enabled. If enabled all DIObjects receive inputs from other objects and write to field devices during the object execution phase in each engine scan cycle. The Enable full interrupts can be enabled. If enabled all objects send and receive updates and all DIObjects on this engine write to and receive update from field devices during the object execution phase in each engine system. ViewEngine A platform needs only 1 ViewEngine, but it can handle more. Multiple InTouch View Applications can be assigned to a single ViewEngine. A ViewEngine can also be used to support the InTouch applications by; providing arrays, workstation specific attributes, global constants managed with a ViewEngine template. Can host multiple InTouch App Instances Can serve as an Active Engine in Runtime o Template for Configuration Settings o Holder of ArchestrA Graphics as Windows Multiple View Engines Can be Used on same Platform Area An Area represents an Area of a plant within a Galaxy. The Area object acts as an alarm concentrator and is used to put other Automation Objects into the context of the actual physical automation layout. Multiple Engines require multiple areas. Avoid assigning large numbers of objects to a single area; break the area into a hierarchy. 500 objects is a good maximum design target, however this is completely subjective to the loading, performance and individual objects. Provides for Object Distribution across Engines o Hierarchical Model o 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 Historization of alarms is done by engine. Page 20 of 28

22 Device Integration Four types of Device Integration objects are in the Galaxy Toolbox 1. Di Client Objects Connect to externally installed and configured DA Servers and Applications 2. Di Network Objects Contain DA Servers in the Runtime Package which is deployed to the Target Platform 3. 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. 4. Redundant Di Objects Choose between two DI Client objects as a provider of Device Items to Application Objects DI Objects Within the Galaxy there are multiple DIObjects that could be used. To connect to devices in the field a device integration object is required. These can either be specific to the PLC you are using or a generic one such as the DDESuitelinkClient, OPCClient or the InTouchProxy. If the OPCClient object is to be used then it is recommended that this object is deployed to the same machine that runs the OPC Server. With OPC a number of permissions are required, locally on the machine these permissions are setup however across the network they have to be configured manually. Placing the OPCClient object on the same machine means the OPC connection is local and the cross network communications is handled using the internal protocol of System Platform, NMX. If for any reason the OPCClient object cannot be deployed to the OPC Server machine, an OPC tunneler should be used. DI objects should only be hosted by a Static Application Engine (i.e. a non-redundant App Engine). A standard DI object should not be put on a redundant engine; doing so will result in the failover of the engine taking longer than required. This is due to the DI object having to unregister all IO on itself and re-registering all IO. The RedundantDIObject should be used and placed on a redundant engine instead; the registering process does not occur in this scenario. The DI objects should be configured with a reconnect script to ensure that the DI object will reconnect to their data source should a disconnect occur. The training manual and Tech Note 300 provide example reconnect scripts for DIObjects. RedundantDIObject Application Server provides redundancy within data acquisition. To do this you must configure two DI Objects (data sources) and a RedundantDIObject. The RDI monitors and controls the DIObject data sources at the object level. Unlike redundant AppEngines, individual DIObject data sources do not have redundancy related states. For practical purposes, they function as standalone objects. Page 21 of 28

23 Only one DIObject data source provides field device data through the RDI at a time. Both data sources must have commonly configured DAGroups. These must be reflected in and channelled through the RDI, which monitors the two DIObject data sources. It also determines which data source is Active at any given time. Both data sources must also have the same item address space. The RDI can be hosted by a Redundant Application Engine. Below shows a screenshot of how the Redundant DI object sits on the redundant engine with the DI Objects sitting on non-redundant engines. PingItem Within the RDI, under the Scan Group tab, the user can configure a Ping Item. The Ping Item is configured per Scan Group. It s recommended to use an item that is less dependent upon the tags in the PLC to avoid the ping item becoming invalid. Such as: $SYS$FREEMEM, $SYS$TOTALMEM, $SYS$REVISION, etc. Any of these items require the DAServer to connect to the PLC to get the information periodically. Since they are system items they can be used any time to check the connectivity regardless what PLC program has been downloaded to the PLC. If these items are bad then it s definitely a problem with connectivity. If the Ping Item is left blank, it will automatically assign the first known valid item as its Ping Item, however if the object is deployed at a time where no valid item can be found (i.e. a network issue) then a valid item will not be assigned, therefore its best practice to assign a known valid item. DA Server Consider the use of DA Server timeouts, ping the PLC and see what response time you are seeing. The default value is 2000ms. It is recommended that this is reviewed, specifically for PLCs in remote/poor connection areas. For example, if a PLC has a ping response time of over 100ms then it s advised to increase the PLC timeout to around 5000ms. Having the value set higher will avoid early timeouts for PLCs that are in remote areas. Page 22 of 28

24 Use the $DDESUITELINK object to connect to the Wonderware DA Servers or DA Servers that support the Suitelink protocol, e.g. TOPServer. At the Device Group configuration level of the DA Server ensure the Update Interval is set to a prime number; this will prevent multiple Device Groups updating at the exact same time. Each Device Group should have a different prime number Update Interval. At the top level of the DA Server Configuration consider what Poke Mode is required for your system. The default is dependent on the DA Server used. Control Mode Preserves the absolute poke order. This mode is typically used by batch and control applications that depend on the order of the pokes and also on processing of every item poked. Transition Mode Preserves the absolute poke order by keeping the first, second, and last poke values of an item. This mode is used by batch and control applications that depend on the order of pokes but do not process every item poked. Optimization Mode Does not preserve the poke order and has maximum folding by only poking the last value of an item. This mode is typically used by HMI applications. Obviously Control Mode and Transition mode require more work to be done by the DA Server to maintain the order of the pokes. Application Objects Application objects are specific to an application. The application level objects can be contained objects. The objects will be used to instantiate objects. Containment Templates at the Application level should be built into complex structures referred to as containment. This allows you to build up complex parts of the plant that may be duplicated a number of times with speed. Containment should be used at all times where possible, even if there is only one mixer and is not duplicated anywhere in the plant containment should still be used. Using containment will make scripting of IO (assuming the Automatic Assign IO is not used) easier as the contained names can be used where needed without having to refer to instance names. Page 23 of 28

25 Derivation The template structure should be in a logical and ordered manner from the base templates. The base templates supplied with the software are read only, as such all templates should be derived from and prefixed with b_ - e.g. $UserDefined has a derived template of $b_userdefined. These will be the base templates used. The newly created base templates should have any configuration on them that is consistent throughout the galaxy. The next level of derivation is the master templates; these are specific to the plant and include any specific information with regards to the plant which may not be eligible for the base templates. These should be prefixed with $m_ - e.g. $m_valve The third level of derivation is specific to the application you are building. This is the beginning of where your design is being implemented. This is your highest level template with all common functionality on it for the specific type of object, e.g. $Valve. Bear in mind that there is no limitation on the number of templates and the number of templates has no bearing on the running of the live system. The more templates you have the bigger the Galaxy database will be, thus the more load there will be on the database engine and the ArchestrA IDE process. Naming Convention In the design of the system a good naming convention should be considered. The objects name is the objects identity; meaning no other objects should have the same name. An object name uniquely identifies an object in the galaxy. A good example of a naming convention would be the ANSI ISA S5.1/1984 R1992 standard. A contained name uniquely identifies an object within its container. Other objects in the galaxy may have the same contained name but not if they are in the same container. It is advised to ensure that the contained name is descriptive of the role or function in the container, e.g. Inlet_Valve, Outlet_Valve, etc. You may create an object called Valve however the runtime system may require it Page 24 of 28

26 to be called SS01TM3V1. With the contained name you can still refer to this object as Inlet_Valve, this allows you to assign IO easy within scripting. Attributes (Field attributes or UDAs) are the public interfaces of an object; therefore it is recommended that you use a strong naming convention. For example: SP. could be used for Set Points, Cfg. could be used for a configurable parameter. Cmd. could be used for Commands. Also, a good naming convention will incorporate prefixing script names with Scr_ or Script. E.g. Scr_TotalOutput.Calculation or Script.TotalOutput.Calculation. Using a strong naming convention for the Platform and Engines is also advised. This is entirely down to the customer s preference. Using something as simple as AppEngine01 is fine; however it is not necessary to name the AppEngine as AppEngine as the logo does indicate that the instance is an AppEngine. A naming convention could name the AppEngine to match their objects logical split (geographical or function) e.g. NorthEngine, SouthEngine, or ProductXEngine, etc. Individual Object configuration Object Information tab Object Descriptions should be configured so that the users can view what the object is and understand the object without having to review its functionality. Be aware that restoring a Galaxy with a different collation setting may leave this field blank. Therefore it may be necessary to advise that best practice to ensure comments are in here. Scripts In general, considerations should be given to scripts and how they are run. Initialisation scripts can be run OnScan for example, but a script that writes to a text file should be an execute script. Startup and Shutdown scripts should be avoided as much as possible; these scripts can delay deployments and as such if the script takes a long time to execute can result in the deployment timing out. Execute scripts can only run as fast as the engine cycle, as such if you configure and expect a script to run every second but the engine cycle is configured to run every 2 seconds then the script will only run every 2 seconds. When using a trigger type of true/while true, bear in mind that if the expression contains attributes that the quality is not good will not become true and as such will never execute. Page 25 of 28

27 Consideration should also be given to how the scripts execute, by default the scripts execute synchronously, that is, in the same thread as the engine. Therefore, scripts can block other synchronous scripts from executing if the script is poorly written which will result in an engine scan overrun. Some scripts should be configured to execute asynchronously to ensure that other scripts on the engine can to execute without being affected. A good example of a script that should be asynchronous is one that interacts with a database, this is due to the fact you cannot confirm the status of a database server without first connecting. The rule for scripting no matter what language/application you are using is to comment the script at every occasion. Debugging of scripts is a lot easier with comments, especially 6 months after the script was written. When writing the script for the first time, put in debugging messages which write to the SMC log file using the LogMessage() function. These could be encapsulated with an if-statement which only run if a debug UDA is set to true, so that during the running of the system if something does not work as expected this flag can be turned on to debug the system as it is running. DATACHANGE scripts are always preferred to WHILE running scripts as expressions are only evaluated upon data change, not always. Database Scripting Using the functionality of the.net Framework it is possible to create a connection to a database via an object script. However, it is not recommended to create a connection to the database and then close the connection each time the script is executed. Instead, a shared connection should be created at the engine level and then use this connection within your objects so that all objects use the same connection. The connection is not available to other processes on the machine, as such you will need a shared connection on each engine where required and the connection will not be available to ArchestrA graphics as these run within the InTouch View process. When attempting to use the connection it should be checked that it is active, if it is not then a reconnect should be triggered. An example of keeping the connection alive is to periodically run a basic query to the database such as SELECT 1 this will result in the database server simply returning 1. An example of shared connections can be found on page 98 of the Application Server Scripting guide. Any connection to a database that is used to write or return values, to and from a database, should be periodically closed; so that the memory used by the connection and transactions can be released. Failure to do this can result in a memory leak, which could cause the engine to run out of memory. Assigning I/O via script When assigning IO within a script it is recommended that the script execution type is execute and using a while true trigger type. The script should also have a small delay prior to executing; this allows the engine to settle down after deploying objects. Page 26 of 28

28 An example of an expression would be as follows; Examples of the Assign I/O scripts can be found within the training manuals. Graphics Keep in mind that a reference is faster than an expression at runtime. i.e. True is faster to load in runtime rather than 1==1. Also look at any animations or conditions that can be grouped, work with the logic that 10 is better than 100 calculations. So if multiple animations can work from the same condition or reference then utilize this. Remember than embedding has a cost in performance, so there can be a negative effect of embedding a graphic that s just a line or a very small addition, it may be worth drawing that element within the main graphic to reduce the amount of embedding. DATACHANGE scripts are always preferred to WHILE running scripts as expressions are only evaluated upon data change, not always. Grouping When drawing a graphic, it is best practice to group all of the static (unanimated) parts of the graphic into a single group. This reduces load on the graphic engine when the graphic is rendered, as the graphic engine will draw the group as a single object, rather than individual graphic elements. Keep in mind Grouping does have a cost, as such having huge amounts of groups for no use can actually be detrimental to performance. Small Graphics If a small graphic or icon is required, create the graphic at the required size. It is not best practice to re-size a complex graphic to a smaller size; this is because the graphic engine will render all graphic elements and animations even if they are too small to see. Standard Graphics Page 27 of 28

29 Standard Graphics are symbols that determine the styling of standard objects such as buttons, panels, switches etc. The graphics should be created in the Graphic Toolbox and then embedded into other graphics as required. Graphics that have already been created for physical entities, such as a pump, can be classed as a standard graphic as well. It should be noted that if a symbol from the default symbol library is used and changes need to be made to the symbol, then a copy of the symbol should be made and used rather than editing the base symbol directly. If no changes to the base symbol are required, then the base symbol can be used directly. Below is an example of how a button can be a standard graphic: Pop Up Graphics Pop up graphics are graphics that combine standard graphics to create generic graphics. Typically such graphics are used as faceplate graphics to display information about an entity. Object Specific Graphics These types of graphics are built and assigned to templates that represent physical entities of the plant, for example: mixers, kettles, reactors, fermenters etc. Object-specific graphics are made up of standard graphics, generic graphics and pop-up graphics. These graphics must be object aware and typically use relative references (Me, MyContainer, MyArea etc.) to animate them. Page 28 of 28