Pre-historian design considerations?

[gleblanc 1]

This may be in the wrong location, but I wasn't sure where else I might put it... Hi folks. I'm working on adding some automation to our assembly plant. One of the stated goals of the current automation effort is to eventually provide a plant-wide network that will allow management to gather data on all of the assembly processes on the line. My predecessor created a simple PLC program using a Click PLC from automation direct. From what I can find, there is no provision for networking this puppy except via the serial port (MODBUS RTU or RS-232). Thus, my following question: What should I be aware of when specifying hardware and writing software for the next project, assuming that I will want to connect this to some breed of historian eventually? Thanks, Greg P.S. I can post a lot more background on what I've got, and what I think I'm planning, but I thought this was probably enough to get started. If not, let me know and I'll overload you with data.

[Ken Moore 23]

Plant wide historians run on servers. Servers connect via TCP/IP (usually). So... You need to get a plant wide, control LAN installed, and connect all you data sources to the LAN. You do not have to connect every device directly, it may make more sense to have "data collection" devices that connect to several non-ethernet sources and then pass the data on. So...all future installs should have an ethernet connection. Next step is to ensure the Historian you select can connect to the devices you have installed. Many use OPC, but dedicated drivers are also used. Do you know what flavor of historian you may use in the future?

[Rod_Hackney 2]

Ken is right - you will need a plant wide network to facilitate your PLCs connecting to a central server as a start. If you want to produce a plant wide system there are many variables that will have to be planned. You will want to see if each of your processes has a PLC/PLCs controlling them and if ethernet connectivity is available from them.

[paulengr 44]

There's more to it than that. Simply "log everything" which is the standard historian approach doesn't work. Then you have lots of data, but the signal-to-noise ratio is extremely low. That's the marketing ploy for historians. Second, historians as a group are databases but they are very screwy databases. As a group don't even think to ask something like "is it SQL-92" or some other standard compatible. No way, no how, never. Even "InSQL" from Wonderware is nothing even close to SQL compatible. I mean, yeah, it will take SQL-like queries and because it is written as a goofy backend connection to Microsoft SQL, that makes it SQL right? Nope. The only exceptions that I'm aware of are the built-in data logger in Cimplicity PE and FactorySQL, both of which simply log to a stock standard SQL server. No goofy nonstandard database needed. Now this matters because...without a lot of mucking around in the backend and playing all kinds of database tricks to say nothing of outright programming, you are 100% gauranteed to spend a lot of time tearing your hair out trying to get useful information back out of the historian. The one thing they all do well, and they do it in spades, is trending. You can get trend charts all day long and the response time is usually pretty good. But outside of trend charts...don't hold your breath. Frequently you can get raw data but that's about it. Expect to spend a LOT of time messing with their front end interface to get anything useful out. Which brings me to the next problem... The historian licenses are bad. But the front end "supervisor/manager" level licensing is out right ridiculous. Most of them seem to charge around $1500-$2500 per SEAT, with the only good news that you can usually set the licenses up "first come, first served" and share them around. Worse yet, any sort of calculation/data analysis engine that takes data and turns it into meaningful things (downtime, productivity, % defective, etc.) will run around $20,000-$50,000. These are U.S. numbers. The trick to making historians useful (at least down the road) is to work backwards. Start with what you want to get out of it. Say that darned Excel report that gets E-mailed everywhere and floats around the plant. Then reverse-engineer how to produce it. I've tried the "log everything" approach several times with different software packages (PI, InSQL, iHistorian) and every time, the signal-to-noise ratio went to ZERO, or nearly zero. Every time I went the other way and realized that I just need "this data" in "this format" or nearly that, then I ended up with a task to log everything into a standard SQL database and use a standard reporting tool such as Jasper Reports or FactorySQL and it's associated reporting tool. And if there are problems with one particular element of the system, I can always work on that and I have options. Once you spend 6 digits for a giant, unwieldy, very user unfriendly, expensive reporting system, you are usually stuck. Nobody is interested in spending that amount of money twice getting rid of the garbage you staked your career on.

[DanW 41]

Wow. Paulengr gets * * * * * for that response. What an insightful analysis of the difficulties in getting useful data from historians. That was very eye-opening. There was more street-smarts analysis there then I've ever read in a controls trade journal. That get 5 stars for excellence from me.

[Jim_S 0]

(If still looking for additional suggestions or alternatives to those already made here) There are some third-party products that can extract more useful (summarized) data from historians. The one I can speak of in detail is XLReporter which extracts historical data via interfaces that are already built to all the major historians, "out of the box" so that part is done for you. It brings it into an Excel spreadsheet so familiarity there. Excel is used as the "design studio" for the report templates, so nothing new to learn. The new version (since the date of this discussion) goes across the network with all connectivity done on at the server.

[paulengr 44]

No change. Note that I've finally worked out a way to get something useful out of an inSQL historian. The "standard" interface for 99% of what you would want out of it is to use a Wide history table. This format breaks SQL semantics so what you have to do is to create a text version of the query and send it to the inSQL (Wonderware Historian) server via the ExecuteSQL system call. This breaks all kinds of other semantics. ExecuteSQL at least in the Microsoft SQL Server implementation requires a string constant. You can't easily parameterize it so trying to make it user friendly (from the front end point of view) is an exercise in futility. It also breaks the query analyzer and probably half a dozen other conventions as well. Instead, you can access the AnalogHistory table (for instance). This works well except that the moment you try to pull in data from more than one tag, it organizes them into vertical lists when normally what you want is one tag per column, organized in "wide format"...so we seem to be back at square one, for the moment. However, you can still apply full SQL magic to this. Create subqueries, one for each tag. Then you can merge them all together with one overall select statement. Works well, does what the "WideHistory" table does, and doesn't break any SQL semantics. At this point I'm beginning to like Wonderware's SQL server SLIGHTLY better than any of the "definitely not SQL" competitors (GE Fanuc, Allen Bradley/PI) for this one reason. I'm still partial though to the built-in data logger in Cimplicity PE and the one in FactorySQL (now Ignition) because they support real SQL. If you just want to "get your feet wet" on this stuff, most of them offer 2 hour licenses. However, GE Fanuc's Historian goes one step further. You can get a limited point historian (it's either 10 or 100 points...I forget how many) for free. That's enough to easily get your feet wet if you want to do some testing and such. Also with respect to the very expensive software suites, I highly recommend that you download Allen Bradley's manuals on their FactoryTalk Metrics and FactoryTalk ProductionCentre products. I didn't say buy them...just read the manuals. The reason is because these products are effectively "canned" production monitoring suites. You can easily create the same type of data collection/organization system yourself without paying for these software products. The manuals show you how the template works. The basic concepts will lead you to understand how to obtain the data you desire...basically what you get from the manuals is a framework on "how to do it". Reading the manuals for historians tells you how to log (and preserve) data but don't go into details on how to organize/categorize it to obtain information. The other "performance metric" type products are just as good, but the particular way that Allen Bradley sets up their templates makes it easier to understand how to set things up...it is less generic this way but probably more useful in the end. Again only reason I'm not a big proponent of AB's performance measurement type tools is the same as the others...for the price, you don't get much because it doesn't really accelerate your development time sufficiently to justify them. You still spend a huge amount of time customizing it to fit your system. I guess it might need to be said again as well...you need to get all your PLC's and such operating on an Ethernet platform. You might need various gateways and other devices to get there but it is critical that you move towards an Ethernet-oriented plantwide network to be able to pull off historian-oriented systems.