WW HMI SCADA Connectivity and Integration - Multi-Galaxy

Transcription

1 Slide 1

2 WW HMI SCADA Connectivity and Integration - Multi-Galaxy Steven L. Weygandt Portfolio Product Manager - Device Integration /Wonderware / #SoftwareRevolution /InvensysVideos /company/wonderware 2013 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.

3 Celestial Navigation: Multi-Galaxy Multi-Galaxy Concepts Multi-Galaxy Services Infrastructure Using Multi-Galaxy Systems Best Practices Slide 3

4 Galaxy Namespace Objects, Application Server Engines and Platforms on computer nodes comprise a single Galaxy scope that has a conceptual boundary which is evident by its namespace hundreds, thousands or even a million or more named references Namespace is global within the Galaxy scope; same named Objects can exist in differently named Galaxies Direct references as well as hierarchical references derived from the model Galaxy scope relates all of the software Objects in a coordinated set and guarantees quick, easy, reliable runtime linking between software Objects via the global namespace Jurisdictional separation of software Objects in Multi-Galaxy architecture - may be linked using new Galaxy to Galaxy communications technology Slide 4

5 Galaxy Scope - Manageability Facilitate cooperation among the team of people responsible for creating, installing, commissioning, operating and maintaining the automation system within their designated Galaxy scope Links data acquisition between field measurement and control devices to associated software Objects within the context of the Galaxy model Team focus on single Galaxy scope associated with a specific business purpose System must be manageable by team members delegated the responsibility and authority over the system; easier task for smaller Galaxies Segmentation by business responsibility is organized such that the automation functions within each single Galaxy achieve supervisory control according to designated financial key performance indicators (KPIs) Slide 5

6 Segmentation Multi-Galaxy Concepts Straightforward task to segment a large automation system into multiple Galaxies Master set of Object templates that covers all of the modeled Objects Each group of modeled Objects is created in a Galaxy deriving from the appropriate master template Each Galaxy may be assembled, deployed and commissioned separately according to the needs of each team Needs fully functioning communications that link between Galaxies Cross Galaxy communications is handled by new services delivered with Wonderware System Platform 2012 R2 and now 2014 Slide 6

7 Capabilities Supporting Multi-Galaxy Linking Remote Galaxy namespace browsing Data exchange between Galaxies Secure authentication of privileges between Galaxies Slide 7

8 Common Control Room Scenario Design for each functional Galaxy at the site/region and design the central Galaxy as well having the following functions Design for the data flow (connectivity) between the Galaxies Design for the transfer of control and alarm handling between control rooms, for desired transfers and for some system failures Configure templates to implement the transfer of control and handling and the fallback timer functions create multiple new Galaxies with unique names import the selection of Platform aapkg into the each Galaxy Configure Platform computer nodes in each Galaxy export each Galaxy as a production CAB file; archive the CAB files Slide 8

9 Virtualized Multi-Galaxy Development System Medium and large automation systems are candidates for virtualization of the development system Key to successful implementation of virtualization for Wonderware System Platform is the selection of robust server and networking hardware Hosting operating system can be Windows Server 2008 R2 or Windows Server 2012 (+ R2) or VMWare AASystemPlatform_Virtual_Implementation.pdf found on WDN of the Invensys Global Technical Support website Slide 9

10 Multi-Galaxy Services Infrastructure New services infrastructure has been implemented with Application Server version 3.6 enhanced with version 4.0 Robust, high-performance, secure inter-galaxy capabilities Minimum effort to configure Multi-Galaxy communications Principal benefit of segmentation of an automation system as multiple Galaxies is reduction in complexity, hence multi-galaxy services are designed as simple interfaces Amount of time needed to integrate multiple separate Galaxies is greatly reduced compared to previous design approaches IDE tools have not changed for managing multiple Galaxies Slide 10

11 History, Alarms and Events Across Multiple Galaxies Historian 11.0 which includes many significant improvements for scaling to very large systems Redundant Historians are supported by simple check-box configuration Configuration for historization is not different when dealing with a single large Galaxy or when aggregating several smaller Galaxies Alarms and Events subsystems continues to be based upon the Distributed Alarm system technology (System Platform 2012 R2) Improvements in alarm archiving & reporting (System Platform 2014) Slide 11

12 ArchestrA Service Bus (ASB) Robust networked system architecture Communications across a variety of TCP network paths are supported, including LAN, WAN, Radio, and Satellite Firewalls and demilitarized zones (DMZ) are accommodated securely by strict reliance upon public Internet communication protocols Security relies upon User/Group identities and authentication served by Microsoft Active Directory Domain Controllers ASB services link communications between Galaxies, translates between protocols Slide 12

13 Naming Galaxies in a Multi-Galaxy Environment Unique names for participating Galaxies are essential All reference strings that specify linking to other Galaxies must include the Galaxy name and a colon as a prefix GalaxyA2:Tank1000.Level.PV Systems of Galaxies which were originally built with the same name i.e. cookie-cutter implementations it is essential to reconstitute them under unique names Slide 13

14 Multi-Galaxy Services Infrastructure Slide 14

15 Using the Galaxy Browser with Multiple Galaxies Slide 15

16 Using InTouch with Multiple Galaxies (ArchestrA Graphics) Slide 16

17 Multiple Historians in Multi-Galaxy Slide 17

18 Alarms & Events in Multi-Galaxy Slide 18

19 Time Synchronization is Required Slide 19

20 Using OwningObject For Switching Remote Galaxy References Simple QuickScript technique: DIM remoteowningobj AS String; IF RGalaxy == THEN remoteowningobj = RObject; ELSE remoteowningobj = RGalaxy + : + RObject; ENDIF; AnalogMeterVert.OwningObject = remoteowningobj; Slide 20

21 Security Considerations All Domain accounts associated with the target Galaxy must be added explicitly to the Roles on the Galaxy where the Cross Galaxy Server is installed and configured The specific User account must have established at least one successful Login to both the source Galaxy and the target Galaxy of a Pair Local user configuration is not supported for the purposes of Multi-Galaxy where there are data exchange write transactions Slide 21

22 Availability - Redundancy and Other Fault-Tolerance Implications Key aspect of long-distance high-availability architectures is recovery time At each level of the architecture, such as Galaxies, databases, virtualization technology and storage array networks, it takes time to restore service components as operational Architectures can be designed to minimize the impact of single failures and to minimize, even eliminate, the local effects of restoration time Segregation as separate Galaxies minimizes the interactive effects when a component failure occurs Slide 22

23 Licensing Each Galaxy in a Multi-Galaxy automation system requires a license that enables the Galaxy Repository, a specified number of Platforms, and a specified number of I/O points Licenses are required for the InTouch HMI (stand-alone or Terminal Services), DA Servers, Historian (one or more based upon tier) and Historian Clients One or more licenses is required for development with the IDE allocation of licenses has not changed with respect to the scope of a Galaxy Counting I/O points for compliance with the licensed count: any Multi-Galaxy remote references which are prefixed with the name of a remote Galaxy are excluded from the total count Slide 23

24 Standardization Centralized corporate development Galaxies - new feature of System Platform 2014 (Application Server 4.0) Template locking AutoSave for System Platform feature Comparison of archived template and instance Objects Carefully evaluate pros vs. cons of Base Template Library (BTL) Good for cookie-cutter systems Not recommended for diverse, complex equipment hierarchies Leverage field controller user-defined namespace (e.g. UDTs) and standardized field reference attributes in Objects Slide 24

25 Standardization Situational Awareness Library - System Platform 2014 (Application Server 4.0) fast configuration, template lockable, common look and feel vetted by the automation industry Virtualization - guest operating system image standardization rapid deployment of System Platform computer nodes standardized performance monitoring (Hyper-V Manager, VMware) remote performance monitoring (Hyper-V Manager, VMware) rapid diagnosis and recovery from component failures efficient expansion by means of cloning (w/ sysprep) Slide 25

26 Namespace Hierarchical Model vs. DI Direct Referencing Browsing across multiple Galaxies enables rapid development and validation of links between segregated operational functions Namespace hierarchical model is important for browsing to establish context of data associated with equipment Traditional approach whereby HMIs are linked directly to device integration objects (DI) limits the understanding of the equipment context Therefore for multi-galaxy architectures it is recommended to always map field device references to equipment instance Objects I the hierarchical model Slide 26

27 What about the WAN traffic? Pairing Galaxies does incur some overhead of network traffic between Galaxy computer nodes Pairing does allow selective linking by means of configuring the ASB service instances, therefore Galaxy-to-Galaxy packet traffic can be isolated to specific Platform computer nodes Traffic between Galaxies is exception based plus a small number of network packets establishing the health of the connection Nonetheless, some improvements in network traffic are being delivered with System Platform 2014 (Application Server 4.0) Slide 27

28 Reduce Complexity by Standardization and Segregation Another word for segregation is encapsulation a principle of object oriented programming Standard object components distributed in multiple Galaxies reduces diagnostic and routine maintenance effort and also greatly facilitates expansion (scaling) Segregation of functional operations into separate Galaxies reduces the size of the operational and maintenance team which assures accountability and agility focusing on specific business goals for that team Complexity is in fact reduced by limiting the number of connections between components isolation top level connections as planned multi-galaxy links Slide 28

29 Information Multi-Galaxy Celestial Navigation in ArchestrA System Platform 2012 R2 Slide 29

30 Slide 30