Tech Tips January 2006

By Control Engineering Staff March 22, 2007

January 31, 2006

TECH TIP OF THE WEEK:

Revisiting the decision for ‘in-house’ or ‘outsource’ project—Part 2

Not all automation projects require outside assistance of system integrators. The plant’s in-house engineers can execute some projects just as well or better. On the other hand, a plant manager with no in-house engineering staff to draw upon is pretty much obliged to outsource the automation work. Tough decisions face the plant manager who has some, but not unlimited, in-house engineering resources.

Here are additional considerations for deciding whether to execute an automation project in-house or outsource it to a system integrator.

Should we go it alone?

  • Will in-house engineers be able to dedicate entire days to the project without interruptions?

  • Can in-house engineers finish the project within the timeframe dictated by business considerations?

  • Do in-house engineers have access to necessary technical tools, such as design software?

  • Does plant management need to maintain tight controls over project design and execution?

  • Will the project involve proprietary processes that must remain trade secrets?

Should we get help?

  • Is there a system integrator available who is willing to commit to a fixed price bid for the work?

  • Is there a system integrator available who has done this kind of work before?

  • Are in-house engineers—due to time constraints or lack of specific knowledge—more likely to provide an ad hoc solution rather than a well-designed and documented system?

  • Is there a hard-and-fast deadline for finishing the project?

Other considerations (Part 1) were presented in the previous ‘Tip of the Week.’

Source: Control Engineering, July 2004, ‘ How to decide if a project should be in-house or outsourced ‘ sidebar in article ‘In-House/Outsource Debate,’ with data from Nol-Tec Systems, NEDDAM Software Technologies, American Standard/Trane, TransAmerican Automation, and AIA Automation.

January 24, 2006

TECH TIP OF THE WEEK:

Revisiting the decision for ‘in-house’ or ‘outsource’ project—Part 1

Not all automation projects require outside assistance of system integrators. The plant’s in-house engineers can execute some projects just as well or better. On the other hand, a plant manager with no in-house engineering staff to draw upon is pretty much obliged to outsource the automation work. Tough decisions face the plant manager who has some, but not unlimited, in-house engineering resources.

Here are some considerations for deciding whether to execute an automation project in-house or outsource it to a system integrator.

Should we go it alone?

  • Is the required technology mature and well understood? Has it been applied before to automation of similar processes?

  • Will this project have a higher return on investment (ROI) than other jobs on which in-house engineers could be working?

  • Do in-house engineers have the experience and skills required to complete the project?

  • Would it be otherwise advantageous to develop more industrial automation expertise in-house?

  • Will the amount of work required fit into the in-house engineers’ existing workload?

Should we get help?

  • Will the proposed automation system be copied from another facility?

  • Will this system be reproduced at other facilities?

  • Will this system be expanded in the future?

  • Would an outside viewpoint help overcome internal disagreements and political issues?

  • Is ROI high enough to make the cost of quick delivery worth the extra expense of outside assistance?

Additional considerations (Part 2) will be presented in the next ‘Tip of the Week.’

Source: Control Engineering, July 2004, ‘ How to decide if a project should be in-house or outsourced ‘ sidebar in article ‘In-House/Outsource Debate,’ with data from Nol-Tec Systems, NEDDAM Software Technologies, American Standard/Trane, TransAmerican Automation, and AIA Automation.

January 17, 2006

TECH TIP OF THE WEEK:

Keeping controls open yet secure

Making control systems more open and interoperable also have made them more vulnerable to malicious acts—internal and external. To avoid what some have called ‘plug and plague,’ here are some suggestions to follow:

  • Dispel myths that feed a false sense of security. Common misconceptions include that security is an IT problem and that obscurity (of PLCs, DCS, embedded or other controls) provides security; another fallacy is that a firewall is all that’s needed for protection.

  • Do a security assessment of risk analysis, including those in control engineering, IT, and others. Rank risks and assess present and proposed safeguards. At the center of any plan are plant assets, and, moving outward, are operating system security (and remote access), application security, intrusion detection, anti-virus protection, firewall, and backups/disaster recovery.

  • Establish rules, communicate and train, and enforce the rules. Visibility and consistency help thwart those who might consider causing trouble.

  • Implement technologies to support security measures. Patches and updates help.

  • Consider security with any upcoming changes; validate and manage updates; and make appropriate changes to related documentation and training. It’s not a one-time effort; you need to assess, audit, check, revise, train, and do it all again regularly.

Additional information is available at the linked source below.

Source: Control Engineering, June 2004, Think Again, ‘ Open and secure controls .’

January 10, 2006

TECH TIP OF THE WEEK:

What to look for in a washdown-duty motor

Industrial electric motors have inherently rugged designs, but still require extra protective features to handle washdown with pressurized fluids and cleaning agents used in food and beverage processing, pharmaceutical manufacturing, and related packaging applications.

In particular, the industry workhorse ac induction motor has been enhanced with ‘washdown-duty’ features, and every major motor manufacturer offers a line of such motors. Here are some provisions to look for when choosing your motor:

  • Double-dip and bake varnish process to encapsulate the stator windings for extra protection against moisture and internal contaminants.

  • Epoxy primer on rotor to resist corrosion.

  • Stainless-steel output shaft (typically 300 Series)

  • Double-sealed, rolling-element bearings with special lubricant to improve lubrication life and resistance to washout, rust, and corrosion.

  • A slinger and contact lip seal fitted to the output shaft extension for added protection against contaminants.

  • Special exterior paint on outside surfaces (white paint is typical for food processing applications).

  • Stainless-steel housing offers an alternative to exterior painting for harsher conditions.

Other washdown motor features include neoprene rubber gaskets on the conduit box and drain holes/fittings in each end plate.

While induction motors dominate the washdown-duty motor sector, brushless servo and stepper motors increasingly are applied in harsh environments. ‘Food-grade’ ac servo motors are specifically designed for food and beverage packaging/handling. These servo motors feature epoxy paint, food-grade bearing grease, and typically up to IP67 ingress protection. A positive air-pressure system is an option for further protection against liquid entry.

Source: Control Engineering, June. 2004 Back to Basics, ‘ Washdown motor anatomy. ‘

January 3, 2006

TECH TIP OF THE WEEK:

Object-oriented programming concisely explained

Advantages of using objects lies in the creation of faster, better, less costly software code—at least if it’s done well.

Objects allow code to be made more modular and allow those modules to be defined more clearly and concisely. As a result, code can be written faster with fewer mistakes and tested more easily; new functionality can be added to the system more easily (often without changing the underlying system code); and it’s generally easier to create custom system interfaces and components because interfaces are more clearly defined.

There is one downside. Object-oriented code, like any other form of code, can be done badly. In that case, it’s generally much worse than bad conventional code—and also harder to understand and can be harder to fix.

In short, object-oriented techniques are:

  • More complex and difficult to master than conventional programming techniques;

  • When done well, they allow software to be created more easily and allow that software to be more reliable and flexible;

  • Applicable at all levels in process control from the vendor’s native code to the scripting provided to the user/integrator to the organization and maintenance of actual process databases and displays; and .

  • Object-oriented techniques do not, in themselves, guarantee a better result. Choose your vendors carefully, test the systems thoroughly, and make sure you understand how well the system will work in practice for your application.

Source: Control Engineering, Feb. 2004 ‘ Object-oriented programming in a nutshell ‘ sidebar and article, ‘Object-Oriented Programming: A Primer.’