PLCs, data logging and analysis, need to get up to speed on available software

Mr. Blah

Member
Join Date
Mar 2012
Location
UK
Posts
3
Hi Everyone,
I need some help and it seems that there is a great collection of people here who understand PLCs and everything about them.

Quick up front disclaimer. I am a tech guy (but am not an engineer) and am new to PLCs. I regularly work with software and IT stuff in an office context.

As I understand, PLCs are used to control machines on a production floor (or to control other electromechanical processes, which are often automated). What I am trying to understand is: how can the data running through the PLCs be used in other ways than just controlling the machines? I know there are some data logging and analysis applications, and I'm really trying to get a grip on what the scope of these systems is.

So I guess my main questions are:
1. What are the different software systems out there to log the data from PLCs and make it more useful?
2. Is there an industry standard? What are the most common software packages? What are the upsides and downsides to each?
3. Do any of them output or interface with things like Minitab?
4. SCADA systems: Do most SCADA systems log this data? What are the best ones that make it most accessible?
5. Does anyone have any good examples of ways logging the data from their PLCs improved processes or produced cost savings?

The more data or leads you can provide me with the better!
Thanks!



A quick story for people interested in why someone might be so desperately trying to learn about PLC data logging and analysis.

Imagine the following scenario:
Company x, who has a complex manufacturing/production system (think refinery, aluminium smelter, or die casting size facility) hires a new plant manager, who has "absolutely crazy" (not his quote) ideas about changing the way everything is done. A number of others are concerned that this guy doesn't know his a** from his elbow, let alone anything about running a plant. New Guy proposes a total change in systems and wants to implement all new different software, which to many others does not seem value adding in any way. Its been a hard couple of years for Company x with the decreasing demand from customers, courtesy of the crisis. If this super expensive system from lets say, a large American conglomerate, doesn't provide absolutely amazing (and it seems unlikely) efficiency improvements in a short period of time to justify its whoppingly large cost, its likely that Company x will go bust and a whole bunch of hard working loyal people will be out of work.

Now imagine that there are a group of people at company x who want to oppose New Guy, go over his head, and try to propose an alternative (and less risky) solution to the most senior management. This group are looking at ways of making the current system better at a much lower total cost and really want to call this guy out on the millions of wasted pounds (or dollars) that are about to be spent.

To be able to do this, they need to quickly understand how they could become more efficient, and getting more data from the production floor, via PLCs has been raised as an idea. The theory goes that if there is much more comprehensive data available, the process techs and industrial engineers will be able to quantify and justify process changes (that seem logical to both the new and older engineers who have been there for years) that will generate cost savings. And they choose a random, helpful and somewhat clueless IT guy to find out what software could provide this additional data.


So... if someone was in a situation like that, and wanted to learn everything they could about all the possible alternatives for collecting, capturing, and acquiring and analysing data from PLCS (and any other data sources on the floor), what direction would you steer them in?

Thank you all in advance for your help :)

Mr. Blah
 
How many PLCs do you have in your plant.
Which brand are they.
Are they already connected to a higher level system.
Do the "crazy changes" involve changing the plcs.
 
Looks like you're in an interesting situation there mate!

I think this thread will have many, many replies and many, many differing opinions. I would suggest not picking a solution based on everyone's opinions, but instead using the information to go to management and say "Hey, there are lots of options. We shouldn't be hasty about this."

I've seen way too many clients rush into foolish and expensive decisions because a flashy salesman arrived and said "Our System can do all this for you!". Said salesman often has no idea about the client's processes, and the client sometimes has even less idea about their own processes and existing systems!

It sounds like Company X already has a sizeable investment in automation systems. I'm surprised that there isn't already a SCADA System of some form in place. Do you have any drawings of what I would call "System Architecture"? For example, a basic network diagram showing PLC make/model, SCADA terminals and network topology. You may already have a SCADA system in place that just isn't being used to full potential. This would help us all understand your existing system a bit better, which would help us point you in the right direction.

I'll try and put some basic answers to your questions to start as well:

1. What are the different software systems out there to log the data from PLCs and make it more useful? There are many, many offerings out there. Some big brand names are WonderWare Intouch, Intellution iFix (or whatever it's called now) and Rockwell RSView. Those are just 3 that come to mind, but there are many. Some very, very simple systems can even just get data directly from a single PLC into Microsoft Excel!
2. Is there an industry standard? What are the most common software packages? What are the upsides and downsides to each? Different industries may prefer different packages, but often it comes down to company choice (we've got 6 other plants using this) as well as availability of local support. I'm not sure about Company X's line if work, but in my area WonderWare Intouch is what I work with 99% of the time and is commonly used by other companies in the field. So I can only really speak for Intouch - it's pretty easy to use and has some powerful add-ins such as HMI Reports and Statistical Process Control. Historical datalogging is a piece of cake, and you can easily integrate it with an industrial SQL server. The downside - it's expensive.
3. Do any of them output or interface with things like Minitab? I haven't used this package before, but if Minitab can get its data from a SQL server or import some form of CSV file then yes, probably.
4. SCADA systems: Do most SCADA systems log this data? What are the best ones that make it most accessible? One of the most basic functions of any HMI packages are logging and trend display. Some use their own proprietary log file formats, others interface with stock standard SQL databases. All the major ones I've worked with have some way of getting data into a SQL database, and from there is normally pretty easy to get it out again for analysis and reporting.
5. Does anyone have any good examples of ways logging the data from their PLCs improved processes or produced cost savings? I do a lot of work with a water utility, and I'd say the biggest use of their HMI package is for picking up problems before they turn into major events. Reviewing the level trend from a reservoir vs. pump run hours might indicate a leak. Slowly increasing pump current might indicate a sewer pump blockage. Alarms are one thing, but sometimes the only way to pick up a problem is for a bit of human evaluation - this doesn't look right. I'd say that it saves them thousands a year in terms of reduced overflows and long running leaks.

There is a little catch though. You can have the best, most expensive package out there but if you don't have good process data then you're wasting your time. If none of the process instruments are calibrated or if half of them are bust, then you're not going to make good decisions by looking at historical data. Same deal if you aren't able to measure critical parameters because there just aren't instruments there. You might need your PLC programmer to add in additional things like run hour accumulators, flow totalizers etc.

To be quite honest, I think what is really required is a professional automation person who is familiar with your process to do a critical review of the system as a whole. They may even find you've got 90% of what you need, it just needs a bit of polish and some of the features turned on!
 
Hi LD,
Sorry I am new to this, will get back to you with more accurate figures asap. I literally didn't know what a PLC was until about a week ago.

Across the whole facility, there would be thousands of I/O points, an uneducated guess would put the number of PLCs in the hundreds perhaps? From an IT perspective, I know there are a number of managed switches, and I'm quite sure there are over 1024 IP addresses in use. There seems to be a mix of brands, primarily Allen Bradley and Siemens i think. Perhaps different processes had different suppliers? There are a lot of places I don't have access to, so finding out the exact info may take a while.

Logic says they must be connected to something - I've heard people talk about "the DCS" system, but dont really know what that comprises, I've been thrown into the deep end. An IT example of "crazy change" is that we run all linux systems now (which are functional and reliable), and are moving lock, stock and barrel to micro$oft, for everything. There are going to be huge system migration costs that no-one seems to care about. I understand the same is happening on the production side. Don't know if the actual PLCs will change. Would they need to?
 
Hi Saffa,
Yah, its a bit of a pickle! I'm with you on the wisdom of not picking a solution, I'm more trying to understand the scope of whats out there so that I can help others make a smart decision. I would feel comfortable saying that the group of people opposing the new GM's move here think he met one of those flashy salesmen... and maybe because hes a bit out of touch he thinks that a big name and gigantic pricetag always equals results.

There is definitely some kind of "system architecture" - haha will try to track down a master network diagram and topology chart for all different departments/processes. Could a scada system be called something else? After reading about them, it seems like there should be one.

The idea of a professional automation person to advise makes logical sense. However the esteemed new leader "let go" of a number of people who would have championed this. Some old school thinking that was perhaps needing to be put out to pasture went with the change, but so did a number of people who knew what they were doing. My impression is the idea of going over this guy's head is to basically put forth "dont waste this money" as an alternative and show that there are other courses of action that haven't been evaluated fully that could be taken.

Side note: Is SQL the standard for most of the scada data systems? I would have thought someone like Oracle or someone would have been in on that in a big way.
 
Hi again Mr Blah,

DCS = Distributed Control System. Loosely the same as SCADA.

I'd suspect you've probably got at least half a dozen PLCs by the sounds of it. One HMI package could probably talk to them all, but if different processes have different vendors, you might have a few different ones. These proprietary systems are the most difficult to interface with, as you often won't have the PLC program available and it'll take a bit of sleuthing for a PLC programmer to find out what's going on inside when trying to give you more insight into your process.

Interesting that you're running all linux systems. I haven't worked much with Linux SCADA systems, but am vaguely aware that they exist. I must say the defacto standard is normally Windows based unfortunately.

most of the SQL databases that come shipped with HMI products tend to be Micro$oft as far as I've seen.

You probably want to screen any of the network layouts etc you you post here, (especially if some clever bugger has the admin passwords next to each router :), can't be too careful these days. we just need a basic idea of whatcha got.

Good luck!
 
>Could a scada system be called something else?
Yes. HMI or DCS

>Don't know if the actual PLCs will change. Would they need to?
No. If it isn't broken, don't fix it. What you need is to get some data from the PLC's; there's no need to change them just to get data from them.

A couple observations.
1) Trending data can reveal a lot to management. One firm has 25 plants scattered across 25 states. They started recording the solids flow totalizers (that indicates how much stuff comes off each line on a daily basis) for each of the 4 lines in each plant.

Management at headquarters was shocked at how often the flow totalizer flat lined, indicating the line was powered but not running, or when the flow totalizer signal disappeared, meaning the line was powered down - broken, turned off, down for repairs, whatever.

It goes back to the basics that you have to measure what you want to improve. Without a measurement, how to you know where you started or how far you've come.

2) A DCS is a control hardware/software with very tightly integrated database/historian/control/HMI, targeted primarily at the process industries where the primary end-product is 'stuff' (chemicals/ingots) rather the discrete manufactuers who produce 'things' (widgets).

A DCS is purchased with various modular options, one of which is an historian (the part that logs data and presents it graphically). It would be unusual to find a DCS that doesn't have this option.

It's my opinion that a DCS can be somewhat 'closed': documentation for most DCS's is generally not publicly available; one has to subscribe to a factory service contract to get access to updated documentation. However, those plants I deal with make DCS documentation available to the systems integrators who have to deal with the DCS.

All that said, some of the tools and much of the data for doing what you're asking for are likely available through the existing DCS, unless it is 1970's/early 1980's vintage.

3) A key to what you're trying to do would be OPC, a protocol used for data transfer between systems. It doesn't create a report, or store data, or create a database, it's the means of data transfer.

The HMI/SCADA products mentioned are all OPC clients, which talk to OPC servers. OPC servers have internal drivers that talk to hardware devices to read or to write data from the client to end device. There are numerous firms that offer commercial OPC server software packages (an OPC server runs as a service in Windows) with a large selection of drivers.

4) Maybe the DCS could fetch data from other plants/PLCs. Maybe you need an HMI/SCADA package to do so. But you probably need someone, a systems integrator conversant in OPC and HMI/SCADA to make that happen.

5) A 'scope' document is critical to be able to talk seriously to anyone about how to get this done.

You're pretty loosy-goosy about what you really need to accomplish. That's OK, it's new to you, you don't want your competitor to realize who bad things are (like it's any better at his plant, ha-ha).

But an unwritten scope for a project this size is the path to 'way-over-budget' when it comes to getting it done, or frankly, even discussing it intelligently with a systems integrator (you should be very seriously considering farming this out to a systems integrator).

You (or whoever is leading the revolt) need to write out a scope that lists of the critical data and report requirements, whether that data even exists now (might need new stuff, sensors or programming, just to produce raw data) and if it does, where it exists; then add all those nice-to-have data and report requirements that will triple the cost of the project.

Yes, at this point, writing a scope can be a project in itself, but without a scope, all the talk is just hot air.
 
The answers above have been good, but I'll add my $.02. I recommend contacting Inductive Automation for a demo and information as a starting point. They are experts in the area of PLC <-> SQL/Enterprise integration. To answer your specific questions:

how can the data running through the PLCs be used in other ways than just controlling the machines?
There are lots of applications for your industrial data. Off the top of my head: displaying the data on large digital signage, quality assurance (QA) and downtime tracking, maintenance, alerting/alarming (contacting you), operational efficiency (OEEE type applications), higher level information such as reports, summaries, etc. The common denominator is integrating your process data (from your PLCs) with SQL databases to work with enterprise systems. I would lean toward whatever your IT department is comfortable supporting (MS SQL Server, Oracle, MySQL, PostgreSQL, etc).

I know there are some data logging and analysis applications, and I'm really trying to get a grip on what the scope of these systems is.
This is typically referred to as a "historian". Don't get caught up with that, though. Your best bet is to run it on an IT managed SQL database. Most industrial vendors have historian packages and most basic HMIs support some amount of trending. The bigger historian packages are especially helpful if you have a lot of data that you want to access from many different workstations.

So I guess my main questions are:
1. What are the different software systems out there to log the data from PLCs and make it more useful?
Check out Ignition from Inductive Automation. Most vendor HMI/SCADA packages incorporate this capability to some extent. You also can go with an "SQL datalogger", but then you're on your own on the visualization side.

2. Is there an industry standard? What are the most common software packages? What are the upsides and downsides to each?
You'll get into a Ford versus Chevy or AB versus Siemens argument with this one. My first piece of advice would be to see if what you have meets your needs. If not, clearly define your requirements. Most likely the data portion of it will want to be on an IT supportable standard database system (RDBMS). Your big players in the states are Rockwell Automation and Wonderware. There are many other vendors.

3. Do any of them output or interface with things like Minitab?
I think it's a safe assumption that nobody (in the Industrial Space) will work directly with Minitab. However, any application that deals with an SQL database (and many that don't) should be able to export data sets in a .CSV format. Minitab can import Excel data, so you have enough to run with your statistical analysis.

4. SCADA systems: Do most SCADA systems log this data? What are the best ones that make it most accessible?
Data logging is pretty standard. To be "most accessible", it should be writing to an open (non-proprietary, non-obfuscated) SQL database. Inductive Automation is the industry leader in promoting open access.

5. Does anyone have any good examples of ways logging the data from their PLCs improved processes or produced cost savings?

Check out some of the case studies from Inductive Automation.
 

Similar Topics

Multiple PLCs in our plant communicate using either MSG instructions or Produce/Consume. Is there an industry best practice for documenting this...
Replies
3
Views
743
We have a product we are now building and are planning on using RFID tags to ID trays of product as they move through the process (5 individual...
Replies
6
Views
1,363
Greetings. I have a 1769-L30ER that runs a new piece of equipment my company bought. I would like to read from and write to some tags on this PLC...
Replies
7
Views
1,392
Hello Friends; We have 10 NOS. the machines which were designed in RSLOGIX 5000 and the control system is TT4000 by SOLAR TURBINE. I want to...
Replies
11
Views
3,787
Hi all I have a project on the go and would like to send data from a Siemens 1500 to a Siemens 1200 What is the best function to use ,would it be...
Replies
12
Views
4,337
Back
Top Bottom