Hey all,

I am looking for some general information about OPC and what it can do. We are looking into putting in a OEE (Overall Equipment Effeciency) system in our plant and we have been looking at some vendors for it but it was determined that we would also like to look into doing something in house as an option. Basicly we want to track why a machine was down and for how long.

I've never done anything with tracking this kind of information to the level they want to do it and I'm not sure how to go about it. I've heard a lot of things about OPC applications, software and servers but I don't know a thing about it so I was wondering if someone could give me a kind of intro into it just so I know what I'm dealing with here.

Here's the things I really want to know....

1) What exactly is OPC?
2) In what ways can you interface with it?
3) Does it create reports or is that a seperate software application that data needs to be exported to?
4) Are there limitations to what you can use to connect to it (like brand of PLC and such)

Sorry if I'm way off base and these questions don't make sense, I'm just trying to better understand what this stuff is all about. I appreciated any info, thanks!

You should go to the OPC Foundation (http://www.opcfoundation.org) they have all the detailed infromation that you need and lists of all the participating OPC vendors.

Basically, OPC is broken into 2 catagories, OPC Classic and OPC UA.

OPC Classic is several different types. The most common is OPC DA(Data Access). OPC is a specification of a method of transfering data between applications using COM and DCOM. It is not a programming language though it just specifies how to use COM to accomplish this and it specifies the methods to be used. There are 2 types of OPC applications, servers and clients. Servers produice the data and clients consume the data. The servers acquirte the data from various sources like PLC's, PAC's, CNC's, Databases, etc. The clients take the data that is collected from the servers and can display it or log it or perform any number of tasks. Not all vendors of OPC Servers will support the same device connectivity buty you chould be able to connect almost any device using a combination of servers.

OPC Classic includes OPC DA, OPC HDA(Historical Data Access), OPC AE (Alarms and Events), OPC Batch, OPC Security, OPC DX, and OPC XML-DA.

OPC UA is the next generation of OPC, the UA stamds for Unified Archtitecture. It is based on Web services for data transfer so you are not longer troubled with the vagries of DCOM security. the nice thing is that it wraps the OPC Classic types so that people using those do not have to re-invent the wheel.

Hopefully this anwers some of your questions. If you want to see if there are servers for connecting to your hardware check out our website, http://www.kepware.com.

2) In what ways to you interface with it?

An OPC client is what a human user interfaces with. In the controls world, an OPC client is packaged into some HMI or SCADA software like Wonderware, RSView, OSI PI. The OPC server is also a separate software package which takes on the role of "master driver" that manages the nitty gritty of collecting data from the various field devices and then 'serving' the data to the client, based on "report-on-exception".

So the interaction of an OPC server and an OPC client places machine/process data from the field into your HMI/SCADA OPC client application. It's up to you how you then consume the data in some fashion in the application.

3) Does it create reports or is that a separate software application that data needs to be exported to?
OPC does not create reports. OPC collects data. The application in which the OPC client runs maintains some sort of database from which you would create a report.

4) Are there limitations to what you can use to connect to it (like brand of PLC and such)
OPC servers are the 'drivers' that do the information collection from the field devices. The commercial, certified OPC server packages have extensive lists of devices to which they connect, including generic Modbus ASCII or Modbus RTU. It's my impression that are even programmable scripts that can be run inside an OPC server to tackle various proprietary ASCII devices.

OPC has been in use since the mid 90's so recent models from the major players generally talk some protocol that OPC can handle.

I just thumbed through a Finnish brand refractive index analyzer's app note out on how to interface it to OPC using its proprietary ASCII protocol. The device vendors are being pressed by the market to be 'OPC compliant'. So there's usually some means of getting an OPC server to work with a device.

Dan

System integrators and "efficiency" consultants usually stink at this. You can do it but the key here is that you need to leverage your in-house knowledgebase which is the whole key to achieving the results claimed by OEE proponents. Don't buy the snake oil. There is real value here. But you've got to do it in house. That doesn't mean in house software. It just means in house development. The reason is because "efficiency consultants" don't understand your business. They fail to adequately represent it every time and the result is crap. I can see definitely some value in hiring someone to help set up the software but the moment that they start talking about Excel spreadsheets or anything less than a web-based online reporting system where everyone from operators to the plant manager can see the reports and the data, stop immediately and walk away.

If you want to do OEE simple, then do this. First, pick a number that represents your maximum output in terms of tons per hour, units per day, whatever is the convenient production metric that you use. OEE is a yardstick, and you are defining the units on the yard stick. It doesn't really matter if the OEE result is "10%", "100%", or "1000%". What drives an OEE process is how you measure the key drivers that got you to the number you achieved, and what you can do to improve on them. Now in reality, when you start throwing OEE around, it's usually a good idea to pick numbers so that your current production levels lead to an OEE number around 75%. Psychologically, it looks bad if you throw around 10%, or a number well above 100%. As I said...it's not important but people will assign a certain psychological feel to it.

Now, to calculate OEE, count how many good units you produced (do not count rejects), divided by this maximum. That's OEE. For example, if I decide that my maximum output is 2000 units per day and I actually make 1500, OEE is 75% (1500/2000). If I want to look at it from an overall perspective on a daily basis, there it is. However, if I want to look at how I'm doing "right now", it might be better to look at individual processes and shorten my time down to say an hour, or even 5-10 minutes. This is nice but useless because it gives me a number. I can tell that if I'm doing 75% on one day and 80% on another, the 80% day is 5% better than the 75% day. But it doesn't say anything about how to improve.

Another way to calculate OEE is P X A X Q. P is production. In other words, if I could run the equipment 100% of the time with no defects, how many units would I make? How fast did it actually run? The ratio is P. You need to factor availability (downtime) out of the divisor for this one. For instance, if I can make 60 units/hour and I only made 45 (good or bad), then P would be 75%, during the time that the equipment was available

A is availability. It's simply 100%-downtime%. So if the equipment is down on average 15% of the time, then A is 85%.

Q is quality, or 100% - defect%. So if I make 100 units and 8% are bad, Q is 92%.

Multiplying them together, we get 80%x92%x95% = 58% in this case.

Where this gets more interesting is if you keep track of how many minutes you were down and the cause(s), and how many defects and the cause(s), and look at similar things in terms of lost production. For instance, you can look at % downtime cause because the downstream process prevented you from running. Or in the reverse direction, you can look at the fact that the equipment was available to run (or not...depends on how you want to define things) but how many pieces of lost production happened because of a lack of raw materials (feedstocks), or due to routine cleanings or other non-production activities that stopped the machine. These are often far larger contributors to lost OEE than to a machine "running slow".

The next thing that is usually done is to develop a Pareto chart or ranking where you show all your causes which lowered OEE, and try to find the easiest things that can be fixed which give you the biggest overall performance improvement. It's a good idea to focus on the largest numbers and the nice thing about OEE is that everyone (production, maintenance, quality) are treated as equals. However, sometimes at least at first it is very difficult to improve on the big ones so it's easier to address small ones that produce small but immediate benefits.

It's this last aspect...don't just measure OEE. You could just as easily use the same production numbers that you have now and simply divide by an arbitrary constant. The bigger key to making improvements is in how you break out the things that contribute to a lower score and address those. This kind of reporting doesn't work so well in Excel or even in a reporting package like Crystal Reports because you need the ability to do drill downs and Pareto charts, things that those packages don't do so well.

Going back to the 58% case if I manage to trim defects from 8% to 1.5% and I manage to get downtime down to 0.3%, then my OEE goes from 58% to 74%. My production has gone up from 35 units to 44 units, and I haven't even addressed productivity yet but I'm kind of running out of ways to do much when Q is at 98.5% and A is at 99.7%. So I have to address P, which is often a much tougher nut to crack but given the right incentives and looking for lost opportunities, this can be improved as well to say 91%. At this point, OEE has increased to 90%. Not bad and there's still definitely room for improvement in terms of productivity but we've gone from 35 units of production to 54 units of production out the door, an increase of 54%!

Now, to bring it home, the numbers are not made up. I took them from a real operating plant that put in an MES system and used to drive their OEE process. Yes, quality, production, and downtime really were that awful. In about 2 years time, the plant in question went from the laughing stock of the industry to the gold standard. 1.5% defect rate and 0.3% downtime were effectively unheard of. There was still a lot of room for improvement in terms of productivity, but increasing production over 50% with effectively no major capital dollars is pretty darned good in my book.



Already been answered.



OPC is more or less a standardized interface for software that talks to PLC's. It's basically a standardized driver. Similar to the way that Microsoft created a standard for printer drivers, video drivers, etc. The way that you interface with it is normally through an OPC client software stack. There are several of these but 99% of them simply take the OPC Foundation's free code (free to members that is) and compile it and give it away freely with the OPC server software. So it's not free, but it might as well be.



No.



No.

As to software, there are a number of software packages that do all the calculations "for you" and have the reports already "done". The way that these work is that they come with a prebuilt template or model. You have to sufficiently define characteristics of the hardware in your plant such has what "down" or "up" means. These software packages generally under the title of "MES" (Manufacturing Execution System). There are several of them out there, but they have lots of similar characteristics as follows:

1. You have to have a way to bring the data into the system. That is either an OPC server or an HMI, or a combination of both.
2. The data has to be logged for later data retrieval. You can use a standard database such as a SQL server but the performance is not good enough for certain types of applications. So typically instead of a SQL server, you'd use a data historian.
3. You need software to do the actual calculation of downtimes, quality, etc., to develop the OEE, reasons for downtime, and do a lot of data summing.
4. You need a reporting package to display the results and usually, to interact with them.

In terms of software, in U.S. dollars, #1 is usually $1000 or less. #2 and #4 are usually $3K-$10K depending on how much you buy in terms of licenses. #3 is incredibly expensive for what you get. Most of these packages seem to be around $20K-$50K. You can mix software from different vendors in some cases, but unfortunately you end up losing a lot of features. The best approach is to pick one vendor for all 4 packages except perhaps for the OPC server which is so standardized that it is not terribly important in most cases.

The reason that they are so expensive is that it takes around 3-6 months to develop an OEE system yourself. With the prebuilt models and reporting templates that these packages come with, you can do the same thing in a month or two, given the usual restrictions on time (assuming it's not a full time job). There's not a huge demand (there probably should be), so the result is that they price the software package just slightly less than what it would cost to develop the same report system yourself. The good news is that you get incredible flexibility. If management's definitions of "up/down" time change (they often do), or the production line configuration changes, or someone wants other tweaks done to the model, it's a simple matter to change the configuration files. If you wrote it yourself, this could be a huge undertaking. So if you have the money or can justify it, I'd go with the full blown system.

Now for some vendors. Check out FactoryTalk Metrics from Rockwell (google it). You can even download the manuals (literature.rockwellautomation.com). I suggest you specifically start with reading Rockwell's manuals because if you walk through reading what it takes to configure FactoryTalk Metrics, you will have a good understanding of what the software does and how it works. GE Fanuc makes "Plant Applications" as the MES, "Real Time Information Portal" as the reporting system, and iHistorian as the historian piece. Their system is very good as well and I've successfully used both their canned solution and crafted my own software (taking pointers from the FactoryTalk Metrics manual). OSI sells similar software to augment their PI historian but I've had real problems getting their sales people to talk to me. Wonderware has a similar software suite and they've recently updated it as well. FactorySQL and FactoryPMI and their associated reporting software is probably the lowest cost version out there but they don't have a canned MES engine...you will have to develop your own software. This isn't as bad as it sounds though. There are others but I'm only mentioning ones where I have a good working knowledge.

Regardless, this is a highly integrated endeavor. I can positively say that you stand 0.00001% chance of success if you try to do this without a thorough understanding of PLC's and how they work. I am 99.99% certain that you will end up augmenting the PLC with some extra code that has to be put in purely for the purpose of providing the right data to the MES system. Quite frequently you will require some extra sensors that are not normally required as part of the normal operation of PLC-controlled equipment simply because tracking production wasn't the primary focus of the PLC program. The requirements are usually very low, and I try to do everything I can do use the existing equipment sensors and actuators simply because if you use those sensors and something breaks, production will call maintenance and get it fixed right away. If you have thorough knowledge as a controls engineer, you can often use timers or other alternative tricks to keep the data mostly valid in spite of a bad sensor, or even make equipment modifications that enhance both the OEE data accuracy AND the equipment operation. If you add new stuff that is not required to run the equipment, it gets fixed when someone notices that the MES has bad data in it. By then, the data is all garbage.

Do NOT, whatever you do, wall this program off. It is an integrated endeavor. You WILL require representatives from production, maintenance, engineering, QC, and IT involved in developing it. You should definitely read all the documentation on these systems (actually, the whole team should) before even picking a software package. Part of the reason for doing this is that you really need to understand how these systems work. The whole team needs to be involved in getting this thing off the ground because it cannot be done in isolation, and it cannot be maintained in isolation. If you leave anyone out, the result will be GARBAGE. You might get a working solution, but it will forever have lots of limitations and problems and nobody will be happy with the result. And don't buy those canned hardware modules that various companies want to stuff into your PLC racks, or buy a Historian with the thought that this is the solution by itself. They are not. This is a big deal with lots of pieces involved. And when it comes to coding, be realistic about the time involved. The packages are very expensive but it is very easy to misjudge the months or years of time involved in maintaining a successful system, especially one with lots of in house software.

I've built 5 of these from the ground up and worked with a few more. I have successfully managed to make nearly every mistake in the book with these systems, and I've inherited some from others as well. I'm not pushing Rockwell by the way. The example real plant that I was talking about actually used GE Fanuc's software. At the plant I work at now, I'm thinking in terms of doing the same kind of thing with the software from Wonderware simply because they already have most of the Wonderware modules as it stands. If I didn't have an established HMI and I was doing this from scratch, I'd have to think really hard about whether to go with FactoryPMI. They don't have the prebuilt modelling but depending on the size/complexity of the plant and the amount of modelling effort that is needed, I might lean towards writing that piece of it from scratch again. I'd still rely on someone else for the OPC driver, reporting system, and historian.