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.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- understanding budget and fiscal manag
- understanding stocks and bonds
- understanding finance and investing
- understanding dividends and yield
- understanding money and finance
- understanding bonds and yields
- understanding men and dating
- understanding ratios and proportions
- understanding volts and amps
- understanding death and dying
- understanding amp and speaker ohms
- benefits of understanding learning styles