Best system integration advice for engineering, controls, and IT

Integrating manufacturing and controls with higher-level systems isn’t always easy; here are the top 10 pieces of advice on that and related project management and automation system integration projects in the “Engineering and IT Insight” article series.

11/22/2012


This is the best automation integration advice offered recently in the Control Engineering “Engineering and IT Insight” article series, as measured by online traffic to the posted articles on the Control Engineering website. Dennis Brandl writes on that topic for Control Engineering. Brandl is president of BR&L Consulting in Cary, N.C., focusing on manufacturing IT.

1. UML use cases, sequence diagrams: easily converted into executable code

The combination of state models, use case diagrams (UCDs), and sequence diagrams define the internal logic and behavior of a UML (unified modeling language) system, including how the system will respond to normal and abnormal conditions. When state diagrams, UCDs, and sequence diagrams are combined with UML class diagrams they provide a complete definition of a system which can be easily understood by non-programmers, and can also be rapidly converted into executable code. UML is the software engineering language that all control engineers should understand and start to use in their specification and designs.

UML class diagram on a case packer reduces pages of text to a few simple diagrams where it’s easier to recognize patterns. This shows that the case packer contains a PLC program, uses a failure sensor, and has a PLC program with an author and version, alo2. Understanding UML is an important part of your toolkit

Control system development requires information exchange among many people and systems. UML can help bring out inconsistencies, remove ambiguity, and provide a “standard” way to communicate project information.

3. File this under: Bad habits for control engineers

Don’t fall into the bad habit of using a shared file system to manage project documents. Using a shared file system to manage project documents can result in the following problems:

  • Subject? The file name and directory name are often the only clues to what the document contains.
  • It is not easy to browse a shared file system and take a quick look at the document contents.
  • It is impossible to know the status of a document. Is the document in draft, approved, in rework, waiting for review, or in some other state?
  • It is hard to track multiple versions of a document in a shared file system. 
  • There is no check-out and check-in functionality in a shared file system. 

4. Seven habits of unsuccessful projects

If you have three or more of these project attributes, you need a project "reboot." 1) No architect or architect team. 2) No firm schedule. 3) Schedules are maintained in spreadsheets. 4) Project management has a “failure is not an option” mentality. 5) No configuration management or source control of documents or code. 6) No documentation, test case, or code reviews. 7) Design and test documents are not up-to-date.


UML state models are an extended version of finite state models, which are diagrams containing states and events. This shows a simple nested state model for a device. Courtesy: Control Engineering5. Keep documentation in sync with code

Not keeping an engineering project’s user, design, and test documents up to date with software code is the last bad habit in my short list of the 7 Bad Habits of Unsuccessful Projects (see above). While slipping on this point detracts from usefulness of the engineering or its perceived value, it is a project management bad habit and not an engineering problem. This bad habit occurs when documents are not in sync with a system to be tested or a system to be delivered.

6. Bad project documentation: Break the habit

Think you’re done with a manufacturing IT, automation, or control project? Check your documentation to avoid one of the worst bad habits of projects: Missing, incorrect, poorly written, or incomplete documentation.

7. MES vs. ERP for manufacturing

An enterprise resource planning (ERP) system can support MOM (manufacturing operations management) activities if the basic functionality is supported, the ERP system has a small scope covering a few plants, it supports site-level definitions of workflow procedures, and production can continue for one or more shifts without system availability. Otherwise a manufacturing execution system (MES) solution may be the best answer to your manufacturing operations management needs.

Engineering and IT Insight: A stable physical structure requires at least three main supports. Three “pillars” form the basis for an effective industrial cyber security system: technology, policy and procedures, and people. Courtesy: Dennis Brandl8. 3 pillars of industrial cyber security

A stable physical structure requires at least three main supports. Industrial cyber-security is no different; it requires supporting structures for a stable system. Three “pillars” form the basis for an effective cyber security system: technology, policy and procedures, and people.

9. Future is virtual for manufacturing IT

I have seen the IT future, and the future is virtual. Future IT environments will be built on virtualized systems, and this will include the multiple IT systems used in manufacturing. These include databases, historians, HMIs, schedulers, and even controllers that we use to run our manufacturing operations. Today virtual systems have many forms from internet accessed “cloud” based systems to company owned server farms running hypervisor servers. Virtualization benefits for manufacturing IT include faster applications, start up in hours instead of months, more computer power, and easier upgrades.

10. Do your projects follow Wright’s Law?

Wright’s law, with its proven mathematical formula, gives us an unimpeachable reason to try to maximize reuse of technologies and methodologies in software projects, and organize to build technology expertise. The motivation curve also warns against pigeonholing individuals into specific areas with no chance for improvements. Balancing these two competing forces will allow your software projects to follow Wright’s Law and also maintain a motivated workforce.

- Dennis Brandl is president of BR&L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at dbrandl(at)brlconsulting.com. Compiled by Mark T. Hoske, CFE Media, Control Engineering and Plant Engineering, mhoske@cfemedia.com

www.controleng.com 

www.plantengineering.com.