OPC Tunnel for PlantTriage

Transcription

1 OPC Tunnel for PlantTriage Communication Benefits of an OPC Tunnel to bypass DCOM issues for secure, efficient PlantTriage communication across firewall / WAN Chris Friedman 2 Introduction Chris Friedman - SABIC Innovative Plastics - Information Management Organization / IT - Chemical Engineer - Global and local projects - Mt. Vernon, Indiana site - Multi-site PlantTriage implementation 1

2 Implementation Background 3 Project Goals - Implementation at numerous global sites - Consistent and standard implementation strategy - Separate server(s) by sites Site size and complexity vary considerably Number of loops and users vary - Centralize architecture as much as possible - Minimize hardware footprint and cost - Consistent and robust access to process data - No security risk to process network Implementation Background 4 Data Center Level WAN (Wide Area Network) Central Site Level LAN (Local Area Network) Data Historian Site 1 Site 2 Data Historian Plant / Process Unit Level Process Network Unit 1 Unit 2 Unit 3 Unit 1 Unit 2 Unit 3 2

3 Architecture Concerns 5 Corporate IT - Centralize to data center where possible Ease of maintenance and management Easier hardware replacement - Consolidate servers Fewer servers means less hardware cost Less maintenance cost - Wide Area Network Focus on WAN bandwidth dt and reliability Transparent server location - Consistent and standard architecture Architecture Concerns 6 Local Site IT / Control - Process network Security and firewall not impacted for process network Minimize impact to data traffic load on process network - Data integrity Performance of data transfer appropriate (collection frequency) Accuracy of data collection to PlantTriage - User accessibility Users have robust access to appropriate web / engineering UI Hierarchical data visibility (users can easily find their data) 3

4 Architecture Alternatives 7 Location of PlantTriage server 1) Data center (off-site) 2) Shared server on site LAN (site computer center) 3) Multiple servers on site LAN (per unit / area) 4) Server on process network (per unit /area) Considerations - Data from DCS OPC through firewall or plant historian? - Performance and accessibility - Corporate IT concerns Architecture Alternative # 1 Data Center (Off-site) Data Center Level PlantTriage Server WAN (Wide Area Network) Central 8 Site Level LAN (Local Area Network) Site 1 4

5 Architecture Alternative # 1 9 Data Center (Off-site) - Considerations Network performance, WAN bandwidth and latency Reliability and uptime of WAN Performance of data collection from site across WAN Performance of web pages across WAN Accessibility of PlantTriage engineering interface - Discussion High bandwidth and reliability of WAN (comparable to LAN) Remote desktop access to engineering desktop Several users sharing data (proper hierarchy of data needed) Performance unknown, need testing! Architecture Alternative # 2 Shared Server on Site LAN Site Level LAN (Local Area Network) PlantTriage Server Site 1 10 Plant / Process Unit Level Data Historian? Process Network Unit 1 Unit 2 Unit 3 5

6 Architecture Alternative # 2 Shared Server on Site LAN - Considerations Corporate IT architecture goals Site LAN reliability vs. process network Hardware management responsibility Data shared on same server (security, hierarchy) Loop count limitations per server - Discussion Site LAN reliability and performance good (better than WAN) Site management of server less efficient than centralized Users accessing same server requires proper data hierarchy for efficient visibility No way to secure data by plant area in engineering interface 11 Architecture Alternative # 3 Multiple Servers on Site LAN Site Level LAN (Local Area Network) Multiple PlantTriage Servers Site 1 12 Plant / Process Unit Level Process Network Unit 1 Unit 2 Unit 3 6

7 Architecture Alternative # 3 13 Multiple Servers on Site LAN - Considerations Would physically separate data by plant areas (security) High cost of hardware / maintenance for multiple servers Main users like their own server - Discussion Performance would be good Separation of data and users would be good from security aspect, but Enterprise server needed to see all site data High cost of multiple servers really eliminates this option without some consolidation Eliminate some servers appropriately more like option # 2 Architecture Alternative # 4 14 Server on Process Network Unit 1 PlantTriage Server 7

8 Architecture Alternative # 4 15 Server on Process Network - Considerations Would physically y separate data by plant area / network (security) High cost of hardware / maintenance for multiple servers No server consolidation possible due to network separation Highest performance, robustness due to network diversity No need to cross firewall for data collection, but site network users would not be able to cross firewall - Discussion Hardware / maintenance cost makes this poor option Multiple DCS systems (some with no OPC) eliminates this as a consistent option Support and maintenance would fall to process network group (no IT support) Initial Conclusions 16 - Option 4 - Many DCS types, some without OPC, high cost, lack of access, etc. eliminate this option - Option 3 Too costly for multiple site servers, server consolidation necessary - Option 2 Good option, may require split of servers due to loop counts - Option 1 Best option from cost and management standpoint if performance is comparable to on-site location - Other topic Data historian as standard data collector? Some DCS systems without OPC server OPC / DCOM crossing firewall presents security issue to process network Mixed environment if data historian not standard collector Robust OPC data source required for data historian Historian data structures, performance, configuration, load, etc. are issues 8

9 Key Decision Points 17 - Number of servers minimized according to loop counts - Areas/units to share data and managed through data organization and process - If server footprint is minimized, key decision is location on-site or in off-site data center - Main consideration is performance and reliability - Corporate IT focus makes WAN reliability comparable to LAN - Performance tests over WAN to determine final decision Performance Testing 18 Criteria - 2 second scan rates for 500, 1000, 1500, 2000 loops - Testing to multiple (4) OPC sources and single source - Test to multiple sites (worst WAN case) - Data historian OPC server(s) used for testing - Web site response testing (web page update speed) - Compare response of local server to remote server - Performance data such as network load, CPU use, memory use, disk speed, data processing speed, data accuracy - Stress test to 1 second data (OPC source may be limitation) - Considerations: OPC uses DCOM as underlying communication architecture PlantTriage optimizes traffic through OPC data change callback Tests performed with max stress, all values changing every 2 seconds 9

10 Performance Testing ExperTune PlantTriage Architecture 19 Site Network WAN or LAN? Server at Data Center vs. Local Site Location OPC-DA from data historian PlantTriage Server(s) IIS / ASP.Net Firewall Process Network OPC Server / Data collector Performance Testing Data Center Server - Data Collection 500 loops at 2 seconds from 4 sources same as 500 loops from 1 source At 500 loops, p, 2 second data points being lost every 8 to 30 seconds 1000 loops worse, 1500 loops fails to maintain connection, 2000 loops and PlantTriage fails to start Performance monitors for network, CPU, disk usage, memory usage show these are not limiting factors (on client or server side) Problems due to WAN performance or overloading of OPC server? - Web site response Performance reasonable, compare to local response Latency in WAN will always make remote web server slower Question is how much, is it reasonable? 20 10

11 Performance Testing 21 Data Center Server (500 loops every 2 seconds) PlantTriage Data Historian Performance Testing 22 Data Center Server (500 loops every 2 seconds) OPC OPC 11

12 Performance Testing 23 Local Server - Data Collection 500, 1000 loops per 2 seconds scan with no data loss Stress tested to 1000 loops at 1 second with no data loss 2000 loops per 2 seconds reaches limitations since problems also experienced on local server (external limitation reached) Performance monitors for network, CPU, disk usage, memory usage similar to WAN tests - Web site response Response faster than over WAN, varied by site, traffic, etc. Considered to be reasonable (similar to intranet sites) Performance Testing 24 Data Center Server (1000 loops scanned per 1 second) PlantTriage Data Historian 12

13 Test Conclusions - Remote communication over WAN not acceptable compared to LAN - Data historian OPC server is not the limitation - Issue over WAN not identified as network limitation Performance monitors show low network, resource usage Network not limiting data transfer OPC overhead must be involved Research indicated that DCOM communication degrades with network latency DCOM is cause of issue!!! 25 DCOM - DCOM is underlying communication protocol for OPC - Difficult to configure, most OPC problems related to DCOM - Web research indicates: DCOM works best on networks with low latency and high bandwidth Networking is not OPC s strength since it is based on DCOM OPC was originally developed based on Microsoft COM (component object model) that runs on single computer Most users have difficulty on LAN with OPC/DCOM, and wouldn t even attempt it over a WAN - DCOM requires high h communication overhead Requires handshaking, security layers, user authentication Lots of communication sensitive to latency 26 13

14 OPC Tunnel Possible solution with OPC Tunnel - Best described in depiction - OPC Tunnel eliminates DCOM, making the communication over network much more efficient OPC Server DCOM Network OPC is inefficient over a network due to DCOM. It is worse over WAN due to increased latency. OPC Tunnel COM OPC Server TCP/IP Network 27 OPC Client OPC Tunnel COM OPC Client OPC Tunnel eliminates DCOM. OPC communicates via COM locally on computer and efficiently passes data across network through standard TCP/IP port. Verification - Tests from data center repeated using OPC Tunnel from various vendors - Results proved the theory of DCOM as issue over WAN - Showed performance similar to or better than OPC connection on local LAN loops at 2 seconds scanned into PlantTriage across WAN with no data loss - Server resources (CPU, memory, etc.) showed slight elevation using OPC Tunnel, but no real impact - Performance, configuration, cost, etc. vary by vendor personal preference and testing recommended 28 14

15 Security - OPC Tunnel improves OPC security since DCOM is eliminated No user authentication for DCOM, OPC can be locked down Only connections from clients with OPC Tunnel client can connect to OPC Tunnel server - Common problems related to DCOM configuration are eliminated - OPC Tunnel uses a single TCP/IP socket DCOM uses a range of TCP/IP ports for communication making OPC difficult to control across a firewall With OPC Tunnel, only the single TCP/IP port needs to be allowed to pass through a firewall 29 Caveats - Considerations to note OPC Tunnels vary by vendor, so although an OPC Tunnel is a valid technical solution, specific software should be tested and confirmed to meet specific needs by preference Some settings may need to be investigated for specific OPC Tunnels by vendor, in particular settings for data change mechanisms in OPC Tunnel, which can interfere with the OPC Server callback mechanism used by PlantTriage In other words, values that change infrequently still need to scan and pass a timestamp (Forced Update option of PlantTriage may be needed) Possible for OPC Tunnels to have difficulty reconnecting automatically on occasion when servers reboot or disconnect Still dependent on bandwidth and performance of WAN to be viable 30 15

16 Benefits / Conclusion 31 - Need for DCOM for OPC communication eliminated - Complicated DCOM configuration and common errors avoided - Increased security and control of communication DCOM security configuration headaches are gone Good solution for OPC across firewall - Performance and reliability of OPC data transfer across WAN greatly improved - Enables centralized architecture for PlantTriage servers Benefits / Conclusion 32 Project Goals - Of original goals, following were realized: Centralized architecture for improved server support, cost, etc. Consistent design across sites Robust data collection across WAN and through firewalls Reliable access to engineering interface via Terminal Services Reasonable web access for users on site networks No impact to security and function of process network Goals of all involved parties met 16