How Manufacturing Benefits by Understanding ERP and IT

During the '90s billions of dollars were spent by businesses that bought into the notion that ERP (enterprise resource planning) systems would lead to the "promised land" of gaining competitive advantage. Throughout the evaluation, design, implementation, and testing of ERP systems, the question "How do we tie in manufacturing?" was held at arm's length with the curt answer, "That's not ...

By Dave Harrold, CONTROL ENGINEERING January 1, 2001

KEYWORDS

Software and information integration

Business

Companies

Control architectures

Enterprise resource planning

Information systems

Management information systems

Manufacturing execution systems

Sidebars: Comparing architects

During the ’90s billions of dollars were spent by businesses that bought into the notion that ERP (enterprise resource planning) systems would lead to the ‘promised land’ of gaining competitive advantage. Throughout the evaluation, design, implementation, and testing of ERP systems, the question ‘How do we tie in manufacturing?’ was held at arm’s length with the curt answer, ‘That’s not a big deal; we’ll do that later.’

Well now it’s later, and it turns out integrating manufacturing information with ERP modules is a bigger deal than most ERP consultants understood and business leaders were led to believe. But that’s not news to those in the manufacturing arena; they’ve been patiently waiting to say, ‘I told you so!’

With that now said, everyone needs to understand the promise of ERP remains valid-properly architected, implemented, and operated ERP can help businesses gain competitive advantage. However, gains achieved won’t be sustainable until manufacturing operations are integrated with appropriate ERP modules, and real-time data flows all around the enterprise.

The challenge now is to figure out what, how, where, who, when, and why manufacturing operations can feed the ERP beast before the entire company joins Wall Street’s endangered species list. Learning to speak and collaborate with IT can help save your enterprise in the ever-accelerating e-business world.

PERA divides the enterprise into life-cycle phases. At the end of each developmentphase, a set of deliverables is produced. Within each phase, PERA recognizes theimpact on human roles caused by maximum and minimum levels ofphysical plant and automation.

Architecture is important

Often an idea is born before its time. Such is the case of enterprise architecture and computer integrated manufacturing (CIM). Both frameworks began to evolve in the late ’70s and by the ’80s formalisms and models were the topic of many seminars, books, and presentations, developed by consultants or universities who rightly believed the integration of manufacturing systems with business systems could deliver huge benefits.

Unfortunately, connectivity standards to achieve the integration goal weren’t available. Instead of plug-and-play, millions of lines of custom software were developed (with much still in place today) to allow very specific applications running on very specific computer platforms to ‘talk’ to one another.

The technology just wasn’t ready to support the idea! That doesn’t mean the idea was bad, for it certainly wasn’t. It merely meant the idea couldn’t take-off until technology was ready to support the integration vision. Today, standards and technology make the CIM vision doable, but before leaping in it’s important to develop and follow an enterprise integration plan.

Two enterprise integration architectures with continued popularity are, ‘Zachman Framework for Enterprise Architecture,’ developed by John Zachman, and the ‘Purdue Enterprise Reference Architecture’ (PERA), developed under the guidance of Purdue University (West Lafayette, Ind.) Professor Theodore Williams.

Looking distinctly different, both architectures share similarities and can lead to integration success; however PERA terminology and models are more manufacturing and process-unit focused (and are available free from www.pera.net ).

Getting comfortable

One of the first things manufacturing and operations personnel see in PERA is a life-cycle model that closely resembles models used in grass-root and upgrade projects the world around. (See PERA Enterprise Architecture Example diagram.)

Just as the methodology used by home architects to develop a general floorplan may not include methods and standards required to meet local, state, and federal codes and regulations, PERA is not the complete answer to achieving manufacturing and business system integration. (See Comparing architects sidebar.) PERA does provide a structure for defining functional requirements and ensures what’s physically built fulfills those defined requirements.

At the enterprise definition (master planning) level, functional requirements are represented by high-level data flow diagrams used as an input to the next phase. Within each life-cycle phase more detail is added until the design reaches ‘approved-for-construction’ status.

A reality of life is that people, facilities, and information and control are very interrelated, and it’s impossible to develop anything beyond the simplest application without considering interrelations. PERA recognizes such interrelations and includes ways to address overlaps or gaps that occur during minimum and/or maximum use of automation and equipment. For example, automated data collection reduces the need for humans to collect and check data. Likewise, manually mixing additives in a bucket instead of installing a mix tank increases human involvement.

Despite the many ‘lights out plant’ prophecies, it’s impractical to automate and entirely eliminate human roles. However, it is practical to automate and eliminate human roles that introduce unnecessary variability, create unsafe conditions, or don’t add measurable value to the product being produced.

Plenty of enterprise integration standards and models exist, but most are developed to address a specific industry or group of like industries, much the same way different crafts use different standards in building a home.

For example, a European technical committee (CEN TC310 WG1) is working on advanced information integration solutions for manufacturing; Aachen Information Systems is developing database and meta-database information integration for chemical engineering; ISA has active committees developing enterprise/control system integration (S95) and batch control (S88) standards; and ISO activities are underway to develop a STandard for Exchange of Product data (STEP).

PERA provides an umbrella model that ensures what a user defines as needed and the architect designs, actually gets built and what is built closely resembles the original, approved design, regardless of the subsequent implementation models and standards used. This means, that as manufacturing and business-system integration technologies and tools evolve, PERA provides the glue to ensure objectives and goals defined in the master plan remain in place while addressing the ripple affects of periodic changes and updates to various disciplines.

Enterprises are made up of multi-dimensional architectures consisting of people, control and information, and facilities. A variety of ways are used to define each architecture. The challenge of information integration is getting data from an asset structure through the subject-oriented structure of control and information systems in a way that supports timely and accurate decision-making by operationally organized people.

Similarities exist

Too frequently, and especially as more detail is added to the master plan objectives and goals, manufacturing and information technology personnel find themselves communicating, but with little confidence comprehension is taking place. That’s partly because of terminology, but is mostly caused by different perceptions about the architectural structures that make up the enterprise.

Facilities are most often viewed as assets, while control and information takes on a subject-oriented structure, and people work in operationally oriented organizations. (See Relating Architectures diagram.)

For example, the operational levels (departments) of an enterprise include finance, research, procurement, and production, while facilities (assets) include buildings, rolling stock, tanks, and machinery. Collecting information so people can control facilities requires subject-oriented control and information systems.

To the surprise of many, control systems (old and new) are configured (programmed) using a subject-orientated segregation of things like control loops, pumps, motors, sequences, etc. Few user/operators realize that asset- or unit-oriented graphic displays are the only place where subject-oriented elements are gathered into operationally structured views. That is why people assigned to configure and maintain control systems often expect to find the ‘guts’ of the control system to be asset- or unit-oriented and become disoriented when confronted with a control systems’ subject-oriented structure.

Fortunately (or not) that same subject-oriented structure exists in information technology. For example, data warehouses are a company’s repository of information and thus the ‘go-to’ source for business decision support and knowledge management. But, data warehouses store data in a subject-oriented structure-customer, supplier, product, sales, etc.-and business decisions are made from an operational viewpoint. Graphic displays used by control and automation systems assemble control loops and pumps onto a vessel or machine graphic. Likewise, data information and data marts assemble specific customer, product, and order status data from data warehouses into tables, graphs, and reports formatted to meet the needs of specific user groups. (See related articles in this issue.)

Understanding and appreciating the differences in structures, and the similarities among control and automation and data warehousing systems is a huge benefit in ensuring both communication and comprehension take place as requirements progress through the life-cycle development process.

Addressing the four R’s

Addressing response , resolution , reliability , and repairability (four R’s) for hardware and software applications has been fairly common in control and automation systems over the past 30+ years, but far less common in business systems and office networks.

As more companies engage in e-commerce, supply chain management, and demand built production, they increasingly find they must re-examine and re-apply the ‘four R’s’ throughout the information technology architecture.

Actually the four R’s were not originally part of PERA. It wasn’t until Gary Rathwell, president of Enterprise Consultants (Houston, Tex.) applied his control and automation experience to PERA that the 4R’s were applied to ensure enterprise applications and networks were implemented at the correct architectural level. The result is an enterprise architecture methodology that places software applications (e.g., control, optimization, maintenance, finance, planning, etc.) and hardware networks (e.g., control highways, industrial local- and wide-area networks, and office networks) at the same ‘architectural level’ when they share common 4R characteristics.

Systems having short response times are sometimes called ‘real-time.’ Response time requirements often change as information is passed up and down and around the enterprise. For example, at the controller level, data must be acted upon in a matter of milliseconds or it becomes too ‘stale’ to use; while response times of hours, days, or even weeks may be perfectly adequate for technical and business applications at higher levels.

Usually the resolution of data (averaged, integrated, etc.) should be made by lower level systems to reduce the volume of data transfers to higher level systems.

For example, a fast pressure control loop may need to act on plant data every hundred milliseconds to accomplish smooth control, however operator display of the same data may only be required every two seconds. An optimization application at level 3 might determine new setpoints based on an average of the last two minutes of data; and a predictive maintenance management application at level 5 might use pressure values integrated over the past week.

Just as response and resolution requirements tend to decrease as data ascends the enterprise, reliability and repairability requirements also tend to diminish.

Control system reliability (mean time between failure) is frequently enhanced by incorporating hot-standby redundancy beginning with field devices and extending through controllers, operator interfaces, and communication networks. By contrast, business computers and office networks rarely include redundant hardware because delaying data arrival by minutes or even hours is acceptable, so long as the data eventually arrives.

Often referred to as maintainability or mean time to repair, repairability addresses the time it takes to repair, replace, or upgrade hardware and/or software. Control systems running critical processes incorporate features that make it easy to complete repairs, replacements, and/or upgrades. As enterprise systems and networks require increased ‘up time’, they will incorporate reliability and repairability features common in today’s control systems.

Mr. Rathwell cautions, ‘Many people understand how response, resolution, reliability, and repairability requirements change as data ascends in the enterprise, but fail to understand the consequences when any of this data is communicated back to a lower level application. Since the 4R’s reduce as data ascends, data communicated back to a lower level brings reduced 4R characteristics with it.’

Control engineers recognize this as being similar to process control loop instability caused by the introduction of lag time. Since plant control system personnel understand the importance of applying 4R’s to design, operate, and maintain high-availability systems, they have much to contribute in applying the 4R’s to other levels of the enterprise architecture.

Sharing information

Early gaps in connectivity standards and technologies were major obstacles in integrating manufacturing and business systems, but that’s rapidly changing. Ethernet’s wide acceptance as the physical media has created numerous network hardware options. On the protocol and application side, internationally approved and defacto standards are appearing everywhere.

One internationally approved standard of interest to information integration discussions is ISA S95. S95 is being developed as a multi-part standard that defines the interfaces between business and manufacturing systems. (See Functions and Data Flows Included in ISA S95 diagram.)

ISA-S95.00.01, Enterprise-Control System Integration, Part 1: Models and Terminology , is a dictionary of common terms IT and manufacturing personnel can use to document information shared between business and manufacturing systems. S95 Part 1 defines entities that form the basis for requirements, such as lot, sublot, qualification test, and production schedule. Consistent with PERA’s concept of facilities, people, and control and information, S95 Part 1 includes definitions for exchanging static and dynamic information.

ISA-S95.00.02, Enterprise-Control System Integration, Part 2: Data Structures and Attributes doesn’t add new concepts, but does add more details and examples to explain and illustrate the objects defined in Part 1. For example, Part 2 describes production in terms of personnel available, materials used and produced, equipment used, and segments of production used for scheduling and costing.

Challenged with a goal of making the entire S95 standard usable across multiple industries, a cross-industry definition map is being included for the food, chemical, and electronics industries.

If things go as expected, S95 Part 2 should be an approved standard before April.

Though S95 Parts 1 and 2 do not define a formal protocol or detailed format for information exchange between systems, they do provide a base on which exchanges can take place.

The S95 committee has already begun working on Part 3 (expected to take 18 to 24 months to complete) to define models for the disparate collection of activities that must occur between manufacturing operations and business logistic systems to finally achieve the integrated enterprise vision.

XML (eXtensable Markup Language) schema definitions aren’t finalized by Web standards organizations, but that hasn’t held back several S95 committee member companies, who are ‘betting’ XML will be the defacto standard for exchanging information. These companies have embarked to create solutions to support business and manufacturing information sharing using XML schemas. In fact, XML is such a strong contender to be the enterprise- wide connectivity method, the OPC Foundation (Austin, Tex.) expects to include XML as part of a new OPC (OLE for Process Control) specification. (See related story in this issue.)

Several years ago manufacturing execution systems (MES) partially bridged the manufacturing and business system integration gap now being addressed by S95. However, S95’s scope is broader and expands MES’s discrete manufacturing focus to include continuous and batch processes.

S95’s Part 3 content is deeply rooted in PERA and MES Association (MESA) International Functional models, but with enough detail added that vendors can define interoperable products and help reduce the complexity of different supplier systems.

ISA S95 identifies the functions on each side of the business/control domain most likelyto share data with one another and details a standard format for sharing that data.

Addressing interoperability

ISA S95 addresses interoperability by defining and detailing functions and data flows that occur between business and manufacturing domains.

Commencing with AMR Research’s (Boston, Mass.) electronic product life-cycle management (e-PLM) component definition list, S95 Part 3 will define the minimum, or basic list of functions (components) and data flows an application should include to support manufacturing-to-business domain information exchanges. Armed with a common language that describes requirements, users and vendors are able to more efficiently and accurately communicate requirements and capabilities.

S95 allows flexibility and growth by permitting vendors to add value-added functions beyond the basic S95 function list. For example, a user seeking a new data historian identifies a need for five of the eight basic functions defined by S95, any data historian adhering to the S95 standard would meet the user’s requirements. If functions beyond the scope of S95 are needed, the user would seek suppliers whose products are S95 compliant and provide the extra functions.

Beyond assurance that products adhering to S95 ‘play well with others,’ users are provided the ability to define and shop basic applications, and more easily determine the incremental cost/value of additional functionality.

At the same time, vendors benefit because attention can be spent developing and marketing value-added functionalities.

Enterprises consist of multi-dimensional architectures that integrate people, facilities, and control and information. These architectures use various ways and means to define their structure. The challenge in reaching ERP’s ‘promised land’ is getting data from an asset (facility) structure through the subject-oriented structure of control and information systems in a way that supports timely and accurate decision-making and knowledge management by operationally organized people.

Development and use of an enterprise architecture model, such as PERA, and use of standards-based technology’s help ensure business/manufacturing integration is achieved in a way that enhances an enterprise’s ability to make knowledge-based decisions and gain competitive advantage, well beyond controls, MES, or ERP.

Comparing architects

Right after hitting the lottery, many people begin planning to build a custom-designed dream home. But everyone knows you don’t begin by having lumber, bricks, and mortar delivered to the building site and then hiring a framing crew to start construction.

Custom-built homes require sitting with an architect experienced in designing the style and size home desired. Early in the design process you learn much of the architects lingo and have several interviews to determine how the home will be used by your family, how you socialize, what things are important and not. In short, you follow the architect’s methodology to determine functional requirements. At the appropriate time, the architect involves a designer/builder to ensure a physical design can be safely constructed to meet your functional requirements.

Creation of a robust, flexible, enterprise information integration solution shares a great deal of similarities with a project to build a custom-built home. You don’t start with a pile of routers, switches, and cables and begin assembling. Instead, you begin with an experienced enterprise architect in your industry and company size and together formulate a master plan that defines short- and long-term functional requirements. At the appropriate time, the architect involves a network designer/builder who ensures the physical design meets the defined functional requirements.

Be it a home or an information system, success depends on identifying functional requirements and then designing the physical entity that best meets those requirements.


Related Resources