It’s not only the technology

Sometimes integration between business systems and manufacturing systems seems harder now than in the past. This is not because the problem is harder; in fact, current industrial standards and XML integration schemas are making integration easier. It is more difficult because the underlying technologies are now the same.

By Dennis Brandl, BR&L Consulting March 1, 2004

Sometimes integration between business systems and manufacturing systems seems harder now than in the past. This is not because the problem is harder; in fact, current industrial standards and XML integration schemas are making integration easier. It is more difficult because the underlying technologies are now the same. When control systems were based on proprietary computers with proprietary networks, it was easy to decide where the boundaries lay: the responsibility and technology boundaries were the same. Now the boundaries are fuzzier because we are using Microsoft Windows and Linux servers, commercial databases, and standard networks in control applications.

Often, when it comes time in a project to decide on system partitioning, the technology is often the deciding factor instead of the underlying automation requirements. There is a natural tendency for anyone who knows a tool to try and use it for tasks for which it wasn’t designed. How many of us have used a screwdriver to drive a nail? When we use information technologies in automation, we need to be aware and make IT departments aware that, just because a technology is already being used elsewhere, doesn’t mean it should be used in all places. While existing applications may meet many automation functional requirements, the non-functional requirements of availability, reliability, and stability also need to be considered. There are two simple phrases to remember about non-functional requirements when looking at IT suitability, “real-time waits for no one,” and “you can’t rollback reality.”

When designing IT systems there is usually a performance requirement, such as the average response time for viewing a report, accessing data, or printing a report. Delays in response for business applications can be inconvenient and hurt productivity, but only in special circumstances do they cause monetary losses. Delays in response in real-time systems can be dangerous and expensive. Remember, “real-time waits for no one.” If an operator losses visibility into a process for several minutes due to a network infrastructure failure, people could be put at risk, product could be lost, or equipment damaged. When we use IT systems in automation, we need to be aware of infrastructure implications and application architecture. If a global instance of an application is the IT standard (for example a single data warehouse) and it is used in an automation application, then we have to consider what happens when it becomes temporarily unavailable. This is especially true when the single instance is accessed across a wide area network (WAN). While the functions required by automation and the business might be met by a single application, the fact that real-time systems cannot handle indeterminate delays means that the IT solution is not always the best solution.

Another common aspect of business systems is that most actions can be “rolled back.” In many IT systems, backups are made after each transaction or on a scheduled basis. If an application fails and corrupts the database, then the database is “rolled back” to a “known good” state and the transactions are rerun. Except in special cases—such as business-to-business or business-to-customer communications—most business transactions can be rolled back. However, automation problems are much more “immediate.” Once an action is committed, it is expensive or impossible to reverse. It is expensive to unmake an automobile and impossible to “unmix” a chemical solution. IT applications, which rely on the ability to retry in the event of failure, are generally unsuitable for automation problems. For example, if an automated patch distribution service is used in an automation project and an incorrect patch is sent, in a business environment this can be undone with minimal loses in productivity; in an automation environment this may cause true production loss and even physical damage.

When using IT solutions in automation environments, remember that it’s not just about the technology . A working solution also requires meticulous attention to availability, reliability, and stability requirements. An IT solution should not be applied just because it is available, it must also meet all automation needs.

Author Information
Dennis Brandl, dbrandl@brlconsulting.com , is the president of BR&L Consulting, a consulting firm focusing on manufacturing IT solutions, based in Cary, N.C.