Slashdot Mirror


An IT Infrastructure for Automotive Manufacturing?

papa248 asks: "I have moved into a Launch Project Manager position within my company. The business is with automotive component manufacturing in a Just-In-Time scale, located in the heart of the Motor City. My job will be to facilitate the setup of IT systems in a new assembly plant. This would be office systems, customer broadcast (parts are sequenced so they arrive at the OEM to match a particular vehicle's VIN), shop floor systems for robotic control, PLCs for error-proofing, lot traceability, the whole nine yards. The company (large, Fortune 500) has some very specific specifications for office systems (HP hardware, Windows, Office, etc) but leaves lots of opportunity for the actual production systems. I've been burned in the past because my predecessors have used 'turnkey' solutions from some lesser known, local vendors that write such custom, specific code on ridiculous, non standard PCs and hardware. I'm in a jam right now, because I've got tons of NT4 systems with a semi-custom OS and VB 6 code on it that are literally falling apart. What are your suggestions for setting up manufacturing control systems that leave the flexibility to be upgradeable and redesignable without being locked in to one particular vendor or solution?"

6 of 26 comments (clear)

  1. Consider by Jorkapp · · Score: 2, Informative

    Consider using a cross-platform language like Java. For upgrade-ability, you should write the applications/platforms as modularly as possible. Write once, run everywhere does have its merits.

    --
    Frink: Nice try floyd, but you were designed for scrubbing, and scrubbing is what you shall do.
  2. Think it out by jamey.v · · Score: 5, Informative
    I have spent the last 5 years of my life doing the same thing. My plant finally finished upgrading our entire proprietary system to a new, custom designed data tracking and control system. There are a few things to keep in mind...
    • PLC's are notorius for having poorly written ethernet communications code. They can really screw up your network. We keep them on separate VLANs.
    • Make sure your control software can talk to everything you need on the plant floor.
    • OPC compliance can help, but it can be buggy. Make sure you test all components thouroughly.
    • We had many custom VB6/VB5 programs running on NT. For those that could not be updated easily, or we did not have source code for, or were too expensive to upgrade, we moved them to VMWare ESX Server with the P2V assistant. It was a lifesaver.
    • We use GEFanuc's product iFix for our HMI. There are many other similar products out there from many different vendors. Most of them have very restrictive and expensive licensing. iFix fit us the best at the time.
    • We moved all of the old junk desktop/tower server machines to proper rack mount servers and virtual machines.
    • Develop a good relationship with a good automation integrator. They can help you more than you think.
    If you want specifics, feel free to email me.
  3. Call your local Rockwell dealer by DorianGre · · Score: 4, Insightful

    Seriously, real time control systems on PLC's are going to be over your head. This part is not an IT solution, but an engineering solution. Call your local Rockwell dealer, and get an automation consultant in.

    1. Re:Call your local Rockwell dealer by topham · · Score: 3, Insightful

      I would like to second this.

      PLCs are often used with machinery that can kill workers if it malfunctions.

      While the submitter has every right to want the systems to be 'standard' PCs, The controller cards for talking to the PLCs are probably the only unique thing in the box. The controllers are expensive for a reason.

    2. Re:Call your local Rockwell dealer by Modeftron · · Score: 2, Insightful

      I disagree, the code that covers the "kill workers" protection usually resides in the controllers logic, the poster isn't suggesting (at least that's the way I read it) changing the machine logic but making changes to the human-machine interface or adding an OPC server to gather SCADA information. The controllers are expensive because the OEM's are gluttonous bastards most PLCs or PACs are run by very simple hardware for instance correct me if I'm wrong but the GE Fanuc 90-70 series plc only has two cpu's a general multi-processor (386) and a boolean co-processor (Motorola) with a flash area for OS storage. Now I'm not knocking the good ole 386 chipsets but I think its a misconception to think of these "industrial computers" as anything but what they are: very simple and robust devices, but the cost of the units far exceed their component parts and engineering costs. I spoke with an AB rep not long ago and he mentioned that the profit margin on PLCs are close to 800%

  4. Why ask SlashDot? by Grab · · Score: 2, Informative

    What do you hope to get from here? There are three possible outcomes:-

    1) You take advice from /. and someone asks where you got your info. You get canned, demoted or otherwise removed from the project when you tell them.

    2) You take advice from /. and no-one asks where you got your info. Project fails. Someone asks where you got your info. You get canned or demoted when you tell them.

    3) You take advice from /. and no-one asks where you got your info. Project succeeds. You get credit. This is the best outcome, but let's face it, it's incredibly unlikely since you don't have the technical know-how to make it work.

    More realistically, this is *exactly* what consultants are for. If you specify at the start that flexibility to be upgraded and non-vendor-specific are key requirements, then you'll get advice based on that specification. And a consultant doesn't have to do the work - outsourcing is not compulsory. If you think you can do the work once you've been pointed in the right direction (or hire a team who can do the work), then all you need the consultant for is to provide advice on which systems and architectures to choose.

    Grab.