February 2004
Have you ever heard a MES or other "expert" talking about how they're going to integrate something as complex as an ERP / MRP / MES system into all of a company's processes using a "sensor"? Ask a follow on question such as "what type of sensor do you plan to use" and you typically get the "deer in the headlights" look. Truth is, they don't even know what a sensor is or what it can do.
The seasoned, high paid, consultants know a second buzz word -- "PLC". They'll tell you that they will use a sensor or PLC. Now ask them what type of sensor or PLC, and watch the look on their face. They haven't a clue.
Truth #1 -- most database jockeys don't have a clue how to connect to, or monitor a process. Once you throw data in a database for them -- they know how to generate queries to view and update the data. But that is the easy part. Getting data into the database and getting data out of the database and reintegrated into existing operator interfaces is the challenge.
Truth #2 -- no one can tell you one or two ways to interface to all processes out there. Sometimes you can use a sensor. But why would anyone in their right mind interface a sensor directly to an ERP system? Most likely that data is already sitting out there in a PLC or other device waiting to share itself with others. Data should flow up, and down, the hierarchy of computers.
Truth #3 -- they don't know how to integrate higher level systems into your processes. Normally they want to put all new terminals, computers, or software out there instead of integrating the higher level system into the process. That allows people to use their system. It does not integrate their system into your processes.
At one of our CSIA meetings we had a discussion about how groups such as MESA have blinders on. They do a good job describing MES, but their idea of integrating MES into operations is similar to "sensors". Don't get us wrong. MESA does a great job on MES but a terrible job on integrating MES into the larger context. Sort of like designing the greatest train in the whole world -- but it won't run on existing train tracks.
They also know that if the customer had to pay more to integrate their system into their existing operations -- the total price would be at least twice (if not 4 to 10 times) higher.
So the question remains: how do you connect process information controllers with higher level systems? And the correct answer is: it depends on what type of controllers and data collection equipment are used in the process.
There are many ways to collect process events and data -- bar code readers, operator interfaces, vision systems, PLCs, computers running dedicated data collection programs, SCADA systems, single loop controllers, DCS systems, databases, motion controllers, quality control systems, communications networks and others.
First someone has to define all the data that needs to be collected. They should have three categories: must have, nice to have, wish-list. "Must have" is data that they will pay whatever it takes to get the data. If it requires $10,000 in programming to write a communications driver -- then so be it. "Nice to have" will depend on the price. Most likely they won't pay $10,000 to collect a single piece of data but maybe $1,000 or $10,000 to read 20 "nice to have" pieces of data. "Wish list" is -- if the data is already sitting in a memory bank somewhere that is already being read and you can read it for free -- why not read it?
Successful communications is a two way street. You have to look at how higher level systems will communicate data down to the operators, supervisors, managers, maintenance personnel, and process engineers on the factory / operations floor. Then look at what data goes back up.
To truly integrate higher level systems into the process, you have to use existing operator interfaces, computers, and SCADA systems.
If you want more information regarding the integration of high level systems into a process, we recommend you see our web page on infrastructure and systems architecture. You will see that there are multiple levels of systems in something as complex as manufacturing operations. Have the top most system tied into the lowest level sensor is as ridiculous as having every cell controller using their own, different databases of employees, processes, departments, and bill of materials. There are reasons groups have spent decades and millions of $ to determine these architectures. It is hard to believe more companies do not use this information.
We try to offer a fair and balanced opinion on every page of our website. We would appreciate more information from other users to express their opinions which we will then incorporate. If you have questions or comments please post them on our message board (see button in left hand column) so that others can read and benefit.