4/30/2008

1

Data Historian for PlantTriage CommunicationCommunication

Real-time data historian used as data collector to provide PID loop date to

PlantTriage

Chris Friedman

Introduction

Chris FriedmanSABIC Innovative Plastics

2

- SABIC Innovative Plastics- Information Management Organization / IT- Chemical Engineer- Global and local projects- Mt. Vernon, Indiana site- Multi-site PlantTriage implementationMulti site PlantTriage implementation

4/30/2008

2

Implementation BackgroundProject Goals- Implementation at numerous global sites

3

- 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- Minimize hardware footprint and cost- Consistent and robust access to process data- No security risk to process network

Implementation Background 4

CentralData Center

LevelWAN

(Wide Area Network)

Site LevelSite 1 Site 2

Site Level

Plant / Process Unit Level

LAN (Local Area

Network)

Process Network

Data Historian

Data Historian

Unit 3Unit 2Unit 1Unit 3Unit 2Unit 1

Network

`

DCS / PLC`

DCS / PLC`

DCS / PLC`

DCS / PLC`

DCS / PLC`

DCS / PLC

4/30/2008

3

Architecture ConcernsCorporate IT- Centralize to data center where possible

E f i t d t

5

• 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 and reliabilityocus o ba d dt a d e ab ty• Transparent server location

- Consistent and standard architecture

Architecture ConcernsLocal Site IT / Control- Process network

6

• 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)

4/30/2008

4

Architecture AlternativesLocation of PlantTriage server1) Data center (off-site)

7

2) Server(s) on site LAN (site computer center)3) Server on process network (per unit /area)

Considerations- Data from OPC on process network, through firewall?- Data from historian on site network?Data from historian on site network?- Performance and accessibility- Corporate IT concerns and supportability

Architecture Alternative # 1Data Center (Off-site)

8

CentralData Center

PlantTriageServer

Site 1

Data Center Level WAN

(Wide Area Network)

Site Level

LANLAN (Local Area

Network)

4/30/2008

5

Architecture Alternative # 1Data Center (Off-site)- Considerations

9

• Security and performance of data across WAN• Data collection to site data historians or across firewalls to

process networks, security and performance considerations• Accessibility of PlantTriage engineering interface (Remote

Desktop)

- Discussion• Reliability and performance of WAN• Reliability and performance of WAN• Remote desktop to engineering desktop• Question of best source for collecting data

Architecture Alternative # 2Server on Site LAN

10

Site 1

Site LevelLAN

(L l A

Plant / Process Unit Level

(Local Area Network)

Process Network

Unit 3Unit 2Unit 1

PlantTriageServer

Data Historian?

`

DCS / PLC`

DCS / PLC`

DCS / PLC

4/30/2008

6

Architecture Alternative # 2Server on Site LAN- Considerations

C t IT hit t l t d d d i

11

• Corporate IT architecture goals, standard design• Site LAN / process network load and security• Hardware management responsibility and support• Data collection source consideration similar to offsite

- Discussion• Site LAN reliability and performance good (better than WAN)

Sit / t l IT t• Site / central IT server management• Offsite or onsite dependent on network performance• Still question of best way to collect data in either case

Architecture Alternative # 3

Server on Process Network

12

Unit 1

`

PlantTriage

DCS / PLC

PlantTriage Server

4/30/2008

7

Architecture Alternative # 3Server on Process Network- Considerations

• Would physically separate data by plant area / network (security)

13

p y y p y p ( y)• 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, inability to share data- Discussion

• Hardware / maintenance cost makes this poor option• Multiple DCS systems (some with no OPC) eliminates this as a• 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- Option 3 - Many DCS types, some without OPC, high

cost, lack of access, etc. eliminate this option- Option 2 – Good option, may require split of servers due

14

to loop counts- Option 1 – Best option from cost and management

standpoint if performance is comparable to on-site location (separate topic)

- If architecture is between option 1 and 2, a main decision becomes best way to collect datay

4/30/2008

8

Initial Conclusions- Data historian as standard data collector?

• Many types of DCS systems, even at same site• Some DCS systems without OPC server

15

• OPC / DCOM crossing firewall presents security issue to process network

• No consistent design if data historian not standard collector• Robust OPC data source required for data historian• Historian data architecture, performance, configuration, load, etc.

are issues

Key Decision Points- Data collection through firewall from DCS/PLC OPC

servers

16

- OR data collection from real-time data historian• OPC through process network firewall (OPC Tunnel)?• Load on data historian scans (sufficient scan rate?) vs. load on

DCS/PLC OPC servers• Duplication of scanning• Added complexity to data historian?• Supporting data architecture in historian mode handling• Supporting data architecture in historian, mode handling• Impact to PlantTriage configuration• Cases without OPC

4/30/2008

9

Key Decision Points 17

Site 1LAN (Local Area

Network)PlantTriage

Server

Data Historian

Server

- or -

Process Network

Unit 1

`

DCS / PLC

FirewallOPC through firewall presents problems- OPC based on DCOM, uses many ports

18

• Difficult to manage• Reduces security to process network• OPC Tunnel could be used to reduce traffic to single port, would

require extra layer to manage for each process area

- Data Historian already collecting process data• Only a few, uncommon ports for collecting data from OPC on

process network sustained securityprocess network, sustained security• For those systems without OPC, only option• No extra layers or significant configuration added

4/30/2008

10

Performance and Load

Performance of interfaces vary- Bottleneck on performance, DCS or Process Historian

• Process OPC must provide data to either historian or PlantTriage

19

• Process OPC must provide data to either historian or PlantTriage• OPC server likely limiting factor in direct comparison• Historian interface will have added overhead (~1000 values/sec)• If several DCS systems feed historian, will increase load on

historian OPC and could be an issue

- Data Historian OPC must be fast and robust• Tests confirm fast and reliable historian OPC (5000 values/sec)Tests confirm fast and reliable historian OPC (5000 values/sec) • Interface to DCS/PLC from historian key factor• Historian OPC can be overloaded if too many loops/values

Interface ScanningHistorian interface strategy- Data already being scanned, but not all

• P/I/D values not scanned (slow)

20

• Data scanned in separate, unrelated tags• Data scans slower than desired for PlantTriage• Scan rates may vary based on DCS interfaces (2 – 10 sec)

- Data Historian scan considerations• Purpose of historian to scan and historize data• Faster scans mean more history (or compression adjusted)• Or can duplicate faster scans for PIDs with no historyOr can duplicate faster scans for PIDs, with no history• Can have different scan rates for data types (flow, temp, level)• Some interfaces not based on OPC !

4/30/2008

11

Other Historian FactorsHistorical data- Faster scan rates or duplicate scanning

21

• Faster scan rates means more history / adjust compression• Duplicate scanning means more load on interface / DCS• So is a tradeoff dependent on situation

- Additional slow scans (P/I/D)• Slow scans (15 min – 1 hr) has little load impact• Where to put new data?• Standard data architecture (PID “record”)

PID Data ArchitecturePID “record”- Related fields/records for consistent structure

22

• Same structure for tags as standard• Easier, consistent interface configuration management between

sites (similar architecture/data structure)

- Field data• PV, SP, OP, Mode(s) – fast data (2 – 10 sec), mode < 1 min• P, I, D slow data (15 min – 1hr frequency)

Filt O t l i d ti l l d t• Filter, Out clamp min and max – optional slow data• Modes vary based on DCS / PLC

4/30/2008

12

Mode handlingVariety of mode methods for DCS / PLC- Consistent method for handling various mode types

• Sites up to 6 different DCS / PLC types

23

• Sites up to 6 different DCS / PLC types• Standard mode values for PlantTriage – (MAN, AUTO, CASC)• Map other mode formats to this standard

- Different systems• Delta V, Honeywell, Fisher Provox, NovaTech, ABB, Fanuc, Siemens,

Foxboro, Kepware, others• Multiple bits / values, many modes• Use historian logic to map to standard MAN/AUTO/CASC• Use historian logic to map to standard MAN/AUTO/CASC• Data structure must handle multiple inputs for mapping• Compared to handling all in PlantTriage – makes configuration consistent

PlantTriage ConfigurationMost compelling reason for historian- Data Addressing varies by system

24

• Keep variety of scan configurations in historian• All PlantTriage systems use same historian “addresses”• Can use similar mode scheme for all sites• Works well across different sites and for consolidating servers

(collecting data from several process areas/historians

- Consistent, simple configurationS f it t it• Same from site to site

• Lends itself to automating configuration (CSV files)

4/30/2008

13

Standard ConfigurationData Historian allows for a standard configuration- Data structuring in historian

25

- Data addressing- Modes- Similar management, interfaces, architecture- DCS Interfaces

• Some are not OPC• Would need differing architectures if data not collected from• Would need differing architectures if data not collected from

historian

Important Points- Limitations of interface in historian vs. direct to OPC- Duplication of scans vs. faster historical data- Impact on history (speeding up scan rate)

Scan rates vary by type (flow temp level)

26

- Scan rates, vary by type (flow, temp, level)- Data history compression- Some systems, no OPC- Lots of different DCS/PLC systems, even at same site- Varying OPC addressing syntax all in data historian

interface, consistent addressing in PlantTriageDiff t DCS/PLC t h dl diff t t- Different DCS/PLC systems can handle different amounts of load, have different number of loops

4/30/2008

14

Important Points- Reuse of implemented technology- But no real added technical benefit (data passed through)

27

- Design for data in historian (scan P/I/D/mode, etc.)- Standard configuration, modes- Support with historian for data collection, central support

Negatives- Considerations to note

• Extra effort when loops added or configuration maintenance done• Extra layer of management in historian (but reduces management

f Pl tT i )

28

for PlantTriage)• History and data compression have to be managed if scan rates

increased• Scan rates from historian to DCS can be limited, but due to OPC,

no worse than data pull straight from DCS• Historian OPC can reach limitation on large historian if many

loops are pulled from many DCS systems

4/30/2008

15

Benefits / ConclusionProject Goals- Of original goals, following were realized:

• Method of handling DCS/PLC systems with no OPC server

29

• Consistent design across sites, within site• Standard data architecture in historian for PID data• Method of handling disparate loop mode structures for varying

DCS/PLC systems • Simplified PlantTriage configuration• No added impact to DCS/PLC OPC or network, no need to cross

firewallfirewall• Common way of controlling scan rates• Use of tools already implemented (data historian)