Engineering and IT Insight: Keep your systems from becoming MULES

Manufacturing IT systems can easily become mature, undocumented legacy execution systems (MULES) as requirements change, knowledge is lost, and supporting systems go obsolete. Keep your software relevant by following these tips.

09/19/2011


No one wants their manufacturing IT systems to become MULES: Mature undocumented legacy execution systems. Engineers design systems to meet the known requirements and provide the end users with a system they can easily understand and use. However, over time, requirements will change, knowledge will be lost, and supporting systems such as operating systems and development tools will become obsolete. When this happens, your system will join the herd of MULES. While eventually every system requires migration or decommissioning, there are steps you can take during your development project to slow down the process and provide a better long-term solution to your users.

One of the definitions of mature is inflexible and unyielding. Over time, as small changes are made to software systems, they become more inflexible and unable to be extended. Small changes and patches over time can often limit future changes as the original architecture no longer meets new needs. The first step to slow the MULE system conversion is through a flexible and expandable architecture.

System design tips: While it is impossible to foresee all possible extensions that will be required for your project over the next 10 to 20 years, you can anticipate some extensions and design for them. For example, if your project reads a set of tags to collect information, you may want to read the tag definitions from a file at start-up instead of being hard coded. You may want to make all user displayed text and error messages accessible from a database instead of hard-coded strings, allowing for use with other languages or improved messages in the future. If your system accesses an Ethernet network, make sure that it uses well-established ports and well-defined messages to allow future redirection or use of the messages. Designing a flexible architecture is difficult. It requires the architect to look beyond the current known requirements and anticipate how users would want to extend or use the system. The time spent defining a suitable flexible architecture is often gained later in the project during debugging and commissioning, so a flexible architecture will help your current project in addition to slowing the transformation from a project to a MULE system.

Controls and IT Integration, Control EngineeringMULES are undocumented. This may be because either there was no documentation or the documentation was lost over time. You can fix both of these problems.

The first fix is to document your system using the assumption that the person reading the documentation knows nothing about the original requirements, nothing about the initial execution environment, and nothing about the underlying architecture and the constraints placed by the programming language or execution system. In designing to not become an obsolete system, you must remember that people reading the documentation may not be currently working for the company, and, in some cases, may not yet be out of grade school. Your future readers will not understand elements of the design, requirements, or environment that are second nature to you, so you must document information that you think is obvious.

Finding the information: Once you have documented the obvious and unobvious, it is important to place the information where it can always be retrieved. When you lose the documentation of a MULE system, it becomes a liability and not an asset. If the system fails, nobody wants to touch it or fix it, and most teams will work around the problem until the MULE system can be replaced. Keep the documentation with the code, in the same directories, to increase the chance that it will survive over 5 to 20 years. Keep the documentation in a format that can be read in the future, providing it in the native, RTF (rich text format) and PDF formats.

Support: Keeping the documentation is important, but slowing the legacy part of being a MULE system also involves keeping support information available. Systems are usually called “legacy” when the underlying operating system environments, supporting libraries, or program compilation environments are no longer supported. Because of the speed of change in IT, legacy systems may be less than 5 years old. It’s important to provide future engineers with the proper tools to support your system, and fortunately virtual systems now give you that capability. When you create a project, create the development and support environment in a virtual system.

Snapshot with editors and tools: When you archive the project, include a snapshot of the development and support environment. This environment should include the IDE (integrated development environment) or the compilers and editors you used to create the final project code. Also include the tools used to generate the documentation. If you have ever supported a system where the documentation was in Corel WordPerfect or Apple MacWrite, then you will appreciate having the original tools available when you have to make changes.

A virtual environment also has the advantage of providing the operating system. Microsoft Windows NT and Microsoft Windows XP are no longer commercially available, but many systems that require them are still running. Providing a development environment in a virtual system, including all environment help files, will be an invaluable resource for future support engineers.

Every system eventually will become a MULE system because, eventually, it can’t be changed, can’t be supported, and can’t be understood. You can delay this process and increase the value of your software with a flexible architecture, well-documented systems for novice users and support engineers, and a development environment that will be available 5, 10, or 20 years in the future. This extra work now will pay great dividends to your future replacement.

- 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. Edited by Mark T. Hoske, Control Engineering, www.controleng.com.

Related reading

Engineering and IT Insight: What’s the best manufacturing operations management systems design?—Should your manufacturing operations management (MOM) systems be centralized or distributed? These key considerations can help you decide. MOM includes MES (manufacturing execution systems), LIMS (laboratory information management systems), WMS (warehouse management systems), tank farm management systems, and AMS (asset management systems).

More on MOM: Cut costs with manufacturing IT standards, best practices—If you had the opportunity to reduce automation project costs or times by over 30%, reduce costs for plant-to-enterprise integration by over 70%, or reduce maintenance support costs by over 10%, you would think that most manufacturing engineers or executives would stop ignoring this opportunity. 

Engineering and IT Insight: How to convert a project into a product—Extra effort is required to convert a manufacturing IT project into a successful product. Advice follows on how to do it. (If you’re considering buying software that sounds or test drives more like a project, you may want to look at other software.) 



No comments
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
Each year, a panel of Control Engineering editors and industry expert judges select the System Integrator of the Year Award winners.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
Learn how to increase device reliability in harsh environments and decrease unplanned system downtime.
This eGuide contains a series of articles and videos that considers theoretical and practical; immediate needs and a look into the future.
Learn how to create value with re-use; gain productivity with lean automation and connectivity, and optimize panel design and construction.
Go deep: Automation tackles offshore oil challenges; Ethernet advice; Wireless robotics; Product exclusives; Digital edition exclusives
Lost in the gray scale? How to get effective HMIs; Best practices: Integrate old and new wireless systems; Smart software, networks; Service provider certifications
Fixing PID: Part 2: Tweaking controller strategy; Machine safety networks; Salary survey and career advice; Smart I/O architecture; Product exclusives
The Ask Control Engineering blog covers all aspects of automation, including motors, drives, sensors, motion control, machine control, and embedded systems.
Look at the basics of industrial wireless technologies, wireless concepts, wireless standards, and wireless best practices with Daniel E. Capano of Diversified Technical Services Inc.
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
This is a blog from the trenches – written by engineers who are implementing and upgrading control systems every day across every industry.
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.