How Manufacturing Benefits by Understanding ERP and IT
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!"
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 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. 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.
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.