Tying It All Together

In Pursuit of Plant-Wide Nirvana

By Steve McCormick, Mission Controls Software Engineer

Industrial integrators and their customers have for many years been talking about integrated, "plant-wide" manufacturing systems that eliminate "Islands of Automation." Plant-wide systems tie all plant-floor activities together into a single cohesive information system. Although many have wished it, few have fully achieved such cohesion and functionality.

Getting an information system to work in concert with all aspects of a manufacturing process can be a real challenge. The secret to reaching this rather lofty goal isn't in writing more ladder logic, Visual Basic code, or interfaces between devices or their database structures. The best way to achieve the plant-wide integrated system is to establish a database (back end) that models the business rules and operational flow of the entire facility. Not only will the database become the "crown jewels," by serving as the single repository for queries and reports, it is the central point for validation and often the best place to perform most of the processing and calculations. The issue of designing a practical and powerful schema to model the process is crucial to success and is a topic in itself.

There is clear advantage in using the database as a source of central validation. Terms for the same things can differ from department to department. If the validation logic is performed locally at an HMI or Visual Basic application, the options presented in a drop-down list may not always agree with those established elsewhere in the system to represent the same items. This can include production line names, product attributes, process states, etc. Even if care is taken to ensure that these terms are the same, maintenance is simplified when using the database as the resource, thus centralizing the source of this data.

The issue of centralized processing and calculations also results in ease of maintenance, since the change made in a single stored procedure is immediately deployed the next time the procedure is called. Performance, however, is another advantage that may even outweigh the maintenance issue. Using the database engine for processing where possible is generally much faster than a compiled application running at the client. This is typically desired where the database content is involved with or affected by the process. Some types of processing may be inherent to the client, and will not affect database content directly. An integrator must also watch that database errors (such as referential integrity conflicts or connection errors) would not result in the interruption of a critical process.

The plant-wide model may not always be entirely attainable. There are often obstacles that cannot be avoided. Certain components of the system may have their own methods and proprietary database, or changing an existing database and all the applications that interact with it could be too costly to warrant the benefit of a retrofit. Even when faced with these obstacles, however, an integrator can get closer to that plant-wide nirvana by using the principles of a well-designed schema and exploiting the processing capabilities of a relational database where appropriate.

In conclusion, the emphasis of the front-end components of a system (such as HMIs and Visual Basic screens) should be on the user experience. In n-tier systems this is also true, since the client method calls are made to the middleware that typically communicates with the database. This results in thinner clients that are easier to deploy and maintain. The bottom line is that the design and stability of the database are extremely important and can be the common thread for a plant-wide system.