Operations Management

At the request of one of Emerson Process Experts blog readers who has long commute to and from his office, I started to add podcast recordings at the end of each post to provide an audio version of each post, beginning this past October.

Today, I thought we'd push the envelope a little further by conducting an interview with data management specialists, Bob Lenich and Joanne Salazar. We're discussing the decisions you might consider as you define your operations management strategy and architected solution.

Here's a rough transcript of the podcast interview:

Jim: Where should operations management (also commonly known by the MES acronym) functionality reside within your system architecture?

Joanne: The ISA95 Enterprise-Control System Integration standard defines data models, work activity, and information exchange of operations management activities. ISA has defined a functional hierarchy model within a manufacturing operation that helps companies optimize functions, processes, and data. The activities defined in Levels 3, 2, or 1 are critical to plant safety, reliability, efficiency, product quality, and maintaining regulatory compliance. ISA95 Level 3 functions coordinate the resources (people, equipment, and materials) needed through all process steps to produce the end product. These solutions integrate across plant functions to enable optimized operations.

Bob: Many people correlate MES with ISA Level 3 functionality. These functions are distinctive, yet it can be challenging to determine where MES functionality resides within the system architecture components, especially if the end user is integrating to an Enterprise Resource Planning (ERP) system. Functions need to be evaluated based on organizational structure to determine the best fit for each activity into either the enterprise domain or the real-time plant floor arena. In a practical sense, this analysis defines who owns the function. Technology is then applied to achieve this functional structure. Using solutions from various suppliers can result in product overlaps and gaps in functionality. Each gap or overlap needs to be analyzed to determine how best to address the function.

Jim: Does the selected technology play a role in these decisions?

Joanne: In a way, it is a "Catch 22"; functional alignment activity is independent of the platform; however, in reality, some alignment decisions are dependent on the applications selected. How does an end user determine the best solution?

Bob: The best result is achieved by optimizing the functional organizational structure; then identifying the technology solutions that best meet these needs. It is important to select a long-term solution partner with both experience and a committed technology investment program to help make these alignment decisions. For example, material management from a warehouse and purchasing perspective may best reside in an ERP system; however, materials management within the process (such as tracking lots and adjusting for potency) may best be performed by the MES solution.

Jim: Are there other considerations in this decision process?

Joanne: Yes, the required response time can help determine where the function should reside within the system architecture. Control systems provide response times in subseconds, seconds, minutes, and hours. MES systems typically provide response times of seconds, minutes, hours, shifts, and days. ERP systems respond in days, weeks, and months.

Bob: That is right. However, the ease of integration between the systems can also be a defining factor in determining where functions should reside. Bottom line, each end user needs to evaluate their specific needs and organizational structure, and then work with a committed partner to determine the best solution.

Jim: Joanne, Bob, I really appreciate your time, sharing your insights about operations management with the Emerson Process Experts readers and listeners.

If you have thoughts on this approach or suggestions for future podcasts, I'd love to read or hear them!

MP3 | iTunes

Emerson's DeltaV team announced news of new smart switches for the DeltaV control network. The topic of cyber-security is on the minds of a lot of process manufacturers right now. In fact, the November 2008 issue of Control magazine is devoted to security-related issues for process manufacturers.

I discussed in an earlier post how commercial off-the-shelf (COTS) technologies rapidly advanced the capabilities and performance for all of the process automation systems. Since these technologies are no longer totally proprietary and within the total control of the automation suppliers, security is a fundamental issue that must be addressed by both suppliers and process manufacturers.

The use of COTS technologies, like Ethernet-based control networks, has caused a collision in the worlds of IT and plant automation teams. Much has been written about the competing objectives and methods between these teams. DeltaV product manager, Bob Huba, has been in these discussions for several years, ferreting out requirements in his role managing security for the DeltaV system.

Bob notes that the fundamental premise behind the smart switch is to make it easy for automation engineers to secure their control networks and give them a way to help their IT organization help themselves. They can do this without having to involve the IT group in the setup and ongoing support of the Ethernet-based networks used for process control.

These switches, used to connect workstations, controllers, WirelessHART gateways, and other Ethernet-based devices are built-for-purpose and fully accessible from inside the DeltaV system. The switches are designed to work with the DeltaV control network with no configuration nor network specialization required.

Instead of COTS, the DeltaV team has coined the acronym, POTS--purpose-built, off-the-shelf to describe this class of device.

Bob described how it helps the IT team by saying that they are fully simple network management protocol (SNMP) version 3 capable, which provides three valuable services: authentication, privacy and access control.

With the proper authentication, IT staff members can get view-only access to these switches and incorporate the information into their network management processes. Bob threw a new term I hadn't heard, MIB-II. Google, always my trusty friend, told me it meant Management Information Base, and Wikipedia defined it:

A management information base (MIB) stems from the OSI/ISO Network management model and is a type of database used to manage the devices in a communications network. It comprises a collection of objects in a (virtual) database used to manage entities (such as routers and switches) in a network.

From the automation team's viewpoint, knowing that it's view-only access helps them all sleep better at night. They don't have to know a thing about SNMPs, MIBs, OSIs, ISOs and other IT stuff, which is of great comfort to them.

In addition, for local access to switch information, each switch has a built-in read-only, web browser interface. Process maintenance folk can browse any switch and get the diagnostic information they need.

What automation folks care about is that their automation systems are secure. The smart switches address one of the largest concerns--open Ethernet ports that people can plug into, or add wireless access points to--and open up the control network to all sorts of security risks. The release describes an easy way to prevent this--one-button lockdown:

The one-click lockdown application automatically scans the DeltaV network to find the DeltaV switches and then allows the user the choice to automatically unlock or lock the switches. Unlocking also enables an auto-relock of the switches in 60 minutes if the user does not perform a manual relock before then.

If you can have a way to bring peace between the automation and IT groups, have the level of security you need, and have the ease-of-use so it is in fact used, then Bob just may have ferreted out something good in all those conversations.

MP3 | iTunes

Update: ARC Advisory Group has a nice summary of these smart switches.

When it comes to level 3 of the ANSI/ISA95 model, the production/operations management level, Emerson's Joanne Salazar and Bob Lenich are two very knowledgeable folks. I caught up with them recently in a discussion around this standard.

For those not steeped in the ISA95 standard, Enterprise-Control System Integration, it is the industry standard for information exchange between enterprise and manufacturing control activities and their supporting IT systems. This standard is oriented toward the definition of data models, work activity, and information exchange. ISA has defined four levels within a manufacturing operation that help companies optimize functions, processes, and data. These levels are based on the Purdue Reference Model for Computer Integrated Manufacturing (CIM). The levels include:

• Level 0: physical equipment and facilities
• Level 1: instrumentation, measurements, and equipment health
• Level 2: automation, asset management, and process data collection
• Level 3: operations management, workflow execution, and document management (MES)
• Level 4: transaction-based enterprise management (ERP)

Joanne noted that the level 3 functions are important because they include key work processes: workflow management, recipe control, maintaining records, and optimizing the production process. By addressing these functions, process manufacturers can reduce costs, increase efficiencies, and optimize resource utilization. Manufacturers face price pressure and increasing global competition, and seek ways to squeeze efficiencies from their manufacturing operations. Joanne also commented that process manufacturers have struggled to implement successful solutions that link the real-time plant floor activities with the transactional-based business planning functions.

Bob responded that level 3 functionality can be addressed in a comprehensive manner-including a single recipe for batch-based processes that address both manual and automated activities, life cycle documentation management, and integration of data that is not real-time-but impacts the product (such as lab results.) These level 3 solutions provide "closed loop" control for operations beyond the automated processes, which enables the manufacturer to make better and faster business decisions and optimize their resources.

While Joanne supported this vision, the practical implementation of these solutions has been difficult. Software integration interfaces have historically been time consuming and require extensive testing-not to mention the difficulties that can arise when the support staff must maintain and upgrade the software.

Bob believed this is where standards, such as ISA95 Enterprise Integration, play a big role. By defining data models, common terminology, and information exchange definitions, the integration of various software packages becomes practical in a working plant. Level 3 manufacturing operations software suppliers who adopt these standards make it easier for the process manufacturer to connect solutions from different companies.

By sitting on the ISA95 committee, Bob has had the opportunity to help define this standard. The collaborative effort of suppliers and users in this standard has helped provide a framework for software suppliers that can help to achieve some of the operational efficiencies sought. Bob pointed to Emerson's automation and operations management solutions that communicate--using the ISA88 recipe model--so that the batch process manufacturer can define a single recipe in a single engineering environment. This recipe spans all functions of an operation, both manual and automated, and enables comprehensive data collection. This single recipe approach may streamline change control and reduce the engineering effort.

And that just might squeeze some more efficiency from the manufacturing operations.

MP3 | iTunes

One of the things I'd like to do more in future posts, is to "hand over the keys" to this blog to one of our experts and "let them drive." Today's post is from Joanne Salazar, a member of the Data Management Services team. For those of you who use Twitter, Joanne is @perspective21. Joanne's subject is that area historically defined as manufacturing execution systems (MES). I'll not indent in a quote box for space considerations, but I hope you enjoy Joanne's words below:

The promise of MES has been difficult to achieve over the years, partly due to limited product functionality. MES is broadly defined as an information technology (IT) solution that supports the primary production processes in a production plant. These applications close the gap between ERP systems and production equipment control, distributed control systems (DCS), programmable logic controllers (PLC), and/or supervisory control and data acquisition (SCADA) applications.

MES applications have become essential to support real-time production control, as well as data collection and reporting that is required in order to improve production performance; however, the practical implementation of these systems can be overwhelming and expensive. The challenge of MES solutions lies in the fact that it is broadly defined and impacts virtually every manufacturing function.

Product functionality that enables a batch recipe to span manual workflow and automated processes, provides a consistent operator interface, and generates a comprehensive batch record without custom coding has not been available until now. In this post, I would like to address the benefits of having a SINGLE batch recipe, developed in a SINGLE engineering environment, using ISA S88 and S95 STANDARDS.

SINGLE RECIPE. In all manufacturing facilities, manual and automated processes need to be coordinated. Manual operations may include filter changes, equipment cleaning, and material weigh dispense. Automated processes involve reading instruments and sequencing values, including steps such as heating, agitation, and material transfers.

Manual operations have historically been addressed via SOP's and paper-based procedures. Automation is commonly addressed using a control system. Therefore, a recipe needs to span across both manual and automated systems to be comprehensive. If the manual and automation systems are not addressed by the recipe, coordination and synchronization of activities needs to be forced, requiring additional resources and reducing efficiency.

One comprehensive recipe that spans manual and automated processes can provide:

• links to reference documents (SOPs, MSDS, P&IDs, etc)
• easy, intuitive interface that walks the operator through work instructions
• transparent access to automated activities with easy views of current process status
• ability to capture data from both manual and automated processes
• synchronization of manual and automated steps to ensure right-first-time manufacturing

SINGLE ENGINEERING ENVIRONMENT. To support a single recipe, it is important to have a single engineering environment to create, modify, and maintain the recipes. A single recipe definition reduces development time, minimizes custom interface software, and enables the process experts to define the recipe. This engineering environment can provide:

• ability to write a "library" of modular operations and steps that can be used multiple times within multiple recipes
• ability to initiate sequencing from one system to the other
• authorization and security functions that are defined once and used throughout the manufacturing facility
• easy, intuitive interface that graphically shows the recipe sequence including both manual and automated processes
• seamless, transparent passing of information between the recipe and the automation systems ensuring synchronization of process steps without the need to write custom code
• comprehensive capture of both manual and automated information, including seamless, transparent capture of automation system data to the recipe electronic batch record

ISA S88 and S95 STANDARDS The use of standards to define and implement recipes improves implementation efficiency and reduces the cost to maintain the solution over its life cycle. ISA-95 (S95) Standard, Enterprise-Control System Integration, is the industry standard for information exchange between enterprise and manufacturing control activities and their supporting IT systems. S95 is oriented toward the definition of data models, work activity, and information exchange.

ISA-88 (S88) Standard, Batch Control, provides guidelines for the design and specifications of batch control systems. S88 is oriented toward physical work execution. S88 is based on a well-defined equipment-oriented conceptual structure and a hierarchy of control functions that acknowledge manufacturing management functions and extend all the way to the manufacturing equipment itself.

Products that adhere to these standards provide easier implementation of recipes by using common terminology, providing a structure that allows process experts to define the recipe, enabling software module libraries for common functions, and predefined integration to other software applications. The use of standards also makes it easier to maintain the solution over its life cycle, ensuring that new product software versions will continue to function and communicate properly with other software applications.