How Manufacturing Benefits by Understanding ERP and IT



|How Manufacturing Benefits |

|by Understanding ERP and IT |

|Information integration can only help an enterprise in the ever-accelerating e-business world. |

|Keywords: Software and information integration • Business Companies • Control architectures • Enterprise resource planning • Information systems|

|• Management information systems • Manufacturing execution systems |

| |

|Dave Harrold , CONTROL ENGINEERING |

|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!" |

|[pic] |

| |

|PERA divides the enterprise into life-cycle phases. At the end of each development phase, a set of deliverables is produced. Within each phase, |

|PERA recognizes the impact on human roles caused by maximum and minimum levels of physical plant and automation. |

| |

|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. |

|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 ). |

|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. |

|[pic] |

| |

|Enterprises are made up of multi-dimensional architectures consisting of people, control and information, and facilities. Avariety 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. |

|[pic] |

| |

|ISA S95 identifies the functions on each side of the business/control domain most likely to share data with one another and details a standard |

|format for sharing that data. |

| |

|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 thecorrect 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. |

|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. |

| |

|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 (eXtensiable 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. |

|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. |

|[pic] |

| |

|For more suppliers, go to the Control Engineering Buyer's Guide. |

|Comments? E-mail dharrold@ |

|Control Engineering January 2001 |

| |

| |

| |

[pic]

|Copyright © 2001 Cahners Business Information, a division of the Reed Elsevier plc group |

|Privacy Statement   |  Contact Information |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download