The ZYX s of Control Systems

Size: px
Start display at page:

Download "The ZYX s of Control Systems"

Transcription

1 The ZYX s of Control Systems Speakers: Norman Anderson, Polk County Utilities Standards Certification Education & Training Publishing Conferences & Exhibits 2015 ISA Water / Wastewater and Automatic Controls Symposium August 4-6, 2015 Orlando, Florida, USA

2 Presenter Norman Anderson, P.E. has 10 years experience in the design and commissioning Process Control Systems for the Water Sector. Norman has provided secure and reliable PLC, SCADA, and Network hardware and software architecture designs and provided control system automation solutions for a range of facilities. Norman has an M.S. in EE from Iowa State University and an M.S. in Physics from the University of Florida. 2

3 Presentation Outline Traditional Control System Development How Operations and Maintenance use control systems The disconnect between design and control system use Developing Data Standards Communications in control systems Instrumentation Selection and Data Highways HMI development PLC selection Documenting the Final Results 3

4 Traditional Control System Development a. Selecting instrumentation and data highways b. Developing a tagging scheme c. Selecting PLCs and communication architecture d. Selecting HMI platform and communication to PLCs e. Creating process control loop descriptions... x. Maintenance needs? y. Remote access/alarm annunciation? z. Trending? General approach is to match the physical design process. However, control systems are changing and are becoming data heavy systems. More effort is needed to determine how Big Data will be used. 4

5 How Operator s Use Control Systems Look at it from a water/wastewater operator s perspective Alarms/Trends: This is basically all I use all day Alarms: I need these after hours as well and I will ignore them if there are too many Data: Its required for compliance and I need access to it for reports and permitting compliance. It s also how I make decisions. HMI access: I need to see the HMI so I know what s happening and I can correct process problems Automated control: It makes things easier but I am the one in charge. Need to focus on the ZYX s of traditional development 5

6 How Maintenance Uses Control Systems Look at it from a maintenance perspective Is it EASY? I use trends for troubleshooting. I use alarms to generate work orders. Is it EASY? Need to focus on the ZYX s of traditional development. It s all about how we use data. 6

7 Disconnect Between Design / Integration and O&M Design and implementation focuses on what makes performing these tasks easy not on what s best for the end user. End user s are frustrated and don t trust control systems. How do we get closer to being on the same page? Begin with looking at data needs of the user first and developing a plan based on data needs. Start with standards. Select equipment to meet these needs and ease maintenance OBSTACLES Budgets and Low Bid requirements Historic Design Development Procedures Lack of communication/access to end users But this isn t our first rodeo build upon past work and experience 7

8 Typical Development of Standards and Master Plans Typical Development Process: Often an inventory of existing hardware and systems Often based on preferences and not necessarily a needs analysis Rarely addresses maintenance from the perspective of application maintenance and standard programming Generally done on existing systems not new development Should include data usage, hardware, software, and implementation 8

9 Determining Control System Goals and Needs to Find Direction Determine System Goals Determine Data Needs Minimize/simplify maintenance? High reliability/availability? Reduce/augment staff have remote access? Higher quality / Optimization? Energy, pressure, flow data for Optimization Reliable and consistent critical alarms DEP and Process Control Data Trending Easy access to data Automated reporting Centralized Historian Ethernet based PLC system 9

10 Data Requirements to Meet Goals and Develop Standards What data do we need to meet our goals and requirements? With Big Data these days we can get almost anything we want Don t get caught up with too much or it can be overwhelming Get the right amount of the right data How will data be displayed? Standard graphic layouts, display styles, summaries Standard trends, reports, and data extraction methods What data is needed for the alarms? Develop alarm levels and assign alarms in levels Which alarms need remote annunciation Don t leave this all to last minute integration. With a little bit of effort, specifying, and using past work this can be nailed down to prevent this work from being an afterthought and the building blocks for a fully integrated and consistent utility design. 10

11 Start with the End in Mind All begins with data At the end of the day we are looking at how to produce and consume data The rest is about do we get data from point A to point B Start with these questions: What are the system goals? What data is needed? How will data be used to accomplish our goals? What data types will I have? How do I move and display the data? 11

12 Importance for Water and Wastewater Water and Wastewater Utilities generally have multiple facilities and infrastructure spread across their region. Facility projects are generally done separately leading to islands of automation with the burden on the utility to bring these together. West WWTP WPF-1 With a lack of standards and analysis of data needs each facility is different and difficult to integrate on a consistent platform. This is compounded by the procurement methods of utilities making it difficult to use consistent engineers and integrators and very difficult to correct at a later time. East WWTP 12

13 Communications Once data needs are determined, we need to determine how to get data from instruments to controllers to HMIs. Different layers of communication: Instrumentation Motor Controllers Power Monitoring PLCs HMIs and Servers Backbone / Backhaul communications for Enterprise level Need to evaluate each layer looking at what is best for each independently while still looking at the big picture to prevent a fragmented communication plan Use communications to your advantage. 13

14 Layers of Communications Looking at our communication layers can help us develop and organize our networks Assists in breaking down a complex system Leads to ideas for security 14

15 Selecting Communications LS LS External IP: External IP: Gateway for NAT to enable identical internal addressing but unique address for polling 15

16 Instrument Data Typical way of selecting instruments and data exchange requirements: What do you guys want to use? We ll just use what matches our instrument/plc preference or standard spec. We ll use a data highway to get more data and save money on installation What are the instruments going to be used for? What data do we need What is the best choice to get the job done Digital communications Big Data approach Look for single points of failure when using busses Overwhelming data? Maintenance? 16

17 Operations Viewpoint of Digital Communications for Instruments What do operators see? Busses Highways Nets 17

18 Operations and Maintenance View of Instrument Digital Communication Compounded by the following...and many more 18

19 Instrument Data Considerations Consider these points Looking for extra data for optimization needs or cost savings What will operations and maintenance do with this extra data? Is it useful or is it overload? Have we planned for it? Data is there but its still not free, do we need it now or in the future? Is there a way we can plan for extra data and still give our staff the 4-20mA they are used to, HART? What s the data worth? Physical media Is our installation outdoors? Surge suppression and fiber optic converters? Analog and discrete I/O is basically a star, is a bus adding single points of failure? Can our staff maintain? Is having non-standard cabling and modules killing our maintenance budget and staff? The only way to know is to determine what your operations staff needs and define your data needs and consider the future. 19

20 Critical Data Views and Trends Develop how instrument data will be displayed and used. This is the consumed portion of data usage to complete the process. How will instruments be used in the control strategy and what will happen when an instrument fails or is out of service? Which values are critical for compliance and require trends and integration into reports? Is there a reporting system in place? Is there a need for special trends for analysis and do these need to be developed or can I select a system that will allow for operations to develop these? 20

21 Critical Data Views and Trends 21

22 Historian Should be more than just a data repository Do I need a historian with enhanced trending? Look at tag count closely, can be major cost differences 2,000 tags ~ $ ,000 tags ~ $100,000 If we know our data needs we can figure this out Integration with reporting and other system software, utility ERP systems and GIS How do we get data out of the Historian? Integrated with HMI or separate? 22

23 HMI Systems Select to match data needs, every system is not created the same. Systems tuned for massive I/O Systems developed for multi-facility deployment Polling based systems Highly customizable vs. pre-configured solutions Consistency is key in water/wastewater utilities Design standard displays, objects, popups Colors are important...where used Field HMIs or OITs...thin clients/zero clients Again... Tags = Cost 23

24 HMI Systems 24

25 HMI Systems 25

26 Server Architecture Look at all your server needs HMIs Historian/trending/reporting Clients (Thin and Zero) Security (AD, NTP, , DNS, etc.) Active Directory for security and operator ease for single signons or smartcard logons Virtualization, not for hardware reduction but for system redundancy and backup along with client deployment and simplified management and maintenance servers for alarming Keep it simple, it can get out of control quickly A data intensive environment requires more IT like solutions including cloud computing type technologies 26

27 PLC Selection Look in both directions, instruments and HMIs to determine communication needs Size based on your I/O and control complexity needs. PLC costs vary widely. (Now we look at control) Common components (Now we look at Historical components) Look at where you need control and where you just need I/O...distributed vs. redundant (Now we look at physical layout) Ease of PLC maintenance. How are programs backed up and how is PLC replacement down. What do we need to specify here to ease maintenance? Think about programming...standard function blocks. Think about the simple controls first such as standard motor control blocks, instrumentation blocks, etc. Use past experiences, knowledge, programs and build upon them. 27

28 Lift station PLC Selection Example Maintenance requirements: Simple flash memory backup so no laptop needed Hot swappable modules Solid Communications Easy part replacement with minimal troubleshooting Engineering requirements: More consistent station data More pump information Lower cost Result: Provided PLC with SD cards, hot swap modules and FDR Used Ethernet to reduce hardwired I/O by 70% and provide more data. PLC with Ethernet and use of a backup pump controller eliminated all relay logic, with1 component replacing more than 10 other components Used DNP3 over Cellular for solid communications and more consistent data Cost was lowered on average by approximately $30,000 per site. 28

29 Documentation Documentation Needs More than Just O&Ms Document Continuously as you work Determine Documentation Needs: Equipment and Software O&Ms Network Diagrams and Addressing Tables Printed and raw format copies of programs with comments Control description and graphics guides with operator notes and troubleshooting guidelines? Obtain documentation to assist in the next design/integration Build a library Turn end of project documentation into beginning standards for the next job How will future changes be documented How will program revisions be documented and new applications stored? How will as-built information be kept up to data? Do we need raw format digital files? Try to use project closeout as an opportunity to begin the development of standards, programming libraries, and information for the next job. 29

30 ISA Standards The ISA 5 s, Covering basic control system diagrams and documentation ISA 18 s, Alarming Standards ISA 95, Enterprise-Control System Integration ISA 99 / IEC 62443, Industrial Automation and Controls Systems Security ISA 101, Human-Machine Interfaces... It s coming soon 30

31 Summary Big Data is here and it s our problem to solve: Look at control systems from a different perspective Operations and Maintenance are looking to use data to make their jobs easier and to deliver higher quality products To aid O&M, we are responsible for figuring out how the data is going to be used and how to deliver and display the data By looking at data first we can break a complex control system architecture into simpler building blocks by looking at the layers of communication and what is needed at each layer and how the layers connect New approaches are always met with obstacles such as breaking out of the mold, managing budgets, and mitigating the shock associated with these changes Using documentation can help us in creating new design and development standards that can make creating and deploying new systems more efficient 31