• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Plant Floor to Enterprise Application Integration – OAGIS vs
 

Plant Floor to Enterprise Application Integration – OAGIS vs

on

  • 2,389 views

 

Statistics

Views

Total Views
2,389
Views on SlideShare
2,389
Embed Views
0

Actions

Likes
0
Downloads
93
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Plant Floor to Enterprise Application Integration – OAGIS vs Plant Floor to Enterprise Application Integration – OAGIS vs Document Transcript

    • Chapter 2 Standards for Manufacturing Systems Integration ISA-95 and OAGIS White Paper Series White Paper #1: An Overview and Comparison Authors Charlie Gifford, GE Fanuc Americas David Noller, IBM Corporation O: (208) 788-5434; C: (208) 309-0990 866-405-7060 charlie.gifford@ge.com nollerd@us.ibm.com Em delaHostria, Rockwell Automation Lorenzo Childress, IBM Corporation 440-646-7324 845-231-3093 egdelahostria@ra.rockwell.com childrel@us.ibm.com Alan Boyd, IBM Corporation 561-862-2774 alboyd@us.ibm.com Key Words ANSI/ISA-95, OAGi, OAGIS, EAI, Open Application Group Inc. Open Application Group Integration Specification, Enterprise Application Integration, System Integration, MES, Manufacturing Execution System, Supply Chain Integration, B2MML, Production Management, System Life-Cycle Cost, Software Integration Methods, Manufacturing Schema, Manufacturing Data Modeling Abstract This comparison paper is White Paper #1 of the ISA-95/OAGIS Manufacturing Integration Standards White Paper Series. White Paper #2, OAGIS, ISA-95 and Related Manufacturing Integration Standards, A Survey, explains the related standards that overlap or work in conjunction with ISA-95, Enterprise-Integration Standards, and OAGIS, Open Application Group Integration Specification, in developing manufacturing system architectures. White Paper #3, Possible Convergence Directions for ISA-95 and OAGIS, presents a convergence path and alternatives for manufacturers currently constructing application integration architectures and for standards committees and working groups working through convergence discussions. In comparing ISA-95 and OAGIS, the paper first provides a brief history and structure of each standard and then presents a detailed comparison by noting the areas of overlap, non-overlap, and benefits. This paper is intended to provide a reference point for manufacturers developing their application integration methods and for standards groups going through the analysis necessary to make convergence decisions.
    • Comparison of ISA-95 and OAGIS Table of Contents Overview .........................................................................................................................................6 A Common Vision..................................................................................................................................6 ISA-95 .............................................................................................................................................8 Brief History of ISA-95 (AKA: IEC 62264)...........................................................................................8 Description of ISA-95 Structure............................................................................................................10 Current Status........................................................................................................................................16 Typical Application (examples)............................................................................................................17 OAGIS...........................................................................................................................................21 Brief History of OAGIS1......................................................................................................................21 Description of OAGIS Structure...........................................................................................................22 Current Status........................................................................................................................................23 Typical Application (examples)............................................................................................................24 Example: IBM EIMS...........................................................................................................................................24 Example: Ford Motor Company..........................................................................................................................27 ISA-95 OAGIS Comparison...........................................................................................................31 Data Model Comparison.......................................................................................................................33 Messaging Support Comparison............................................................................................................34 OAGIS Messaging Overview..............................................................................................................................34 ISA-95 Messaging Overview..............................................................................................................................35 Extensibility Comparison......................................................................................................................35 OAGIS Extensibility...........................................................................................................................................35 ISA-95 Extensibility............................................................................................................................................38 Appendix B: Glossary ..........................................................................................................................40 Appendix C: 1Trademarks....................................................................................................................41 Appendix D: References ......................................................................................................................42 © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 2
    • Comparison of ISA-95 and OAGIS List of Figures and Tables © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 3
    • Comparison of ISA-95 and OAGIS Figure 2-1: Standards-Based Application Integration....................................................................7 Figure 2-2: ISA-95 Domain Hierarchy from Purdue Reference Model........................................11 Figure 2-3: ISA-95 Physical (Work / Resource) Hierarchy...........................................................11 Figure 2-4: ISA-95 Data Flows of Interest Supporting Manufacturing Operations.....................12 Management and Exchanges between Levels 3 and 4..................................................................12 Figure 2-5: ISA-95 Information Categories (objects) Handled by Manufacturing Operations Management and Exchanged between Levels 3 and 4..................................................................13 Table 2-1: ISA-95 Product Segment - Sample Forms...................................................................14 Figure 2-6: Example of ISA-95 Production Schedule Information Object Exchanged Between Level 4 and Level 3........................................................................................................................14 Figure 2-7: ISA-95 Generic Detailed Work Activity Model (Part 3) for MOM............................15 Figure 2-8: Example of ISA-95/OAGIS Transaction Composed of Two Basic Messages, Each Formed by an OAGIS Verb- B2MML Noun Combination............................................................16 Figure 2-9: Example of a Sequence of ISA-95 Transactions to Enable a Specific Business Process Scenario – Production Schedule Changes Based on Production Capability Input.........18 Figure 2-10: Example of Set of ISA-95 Transactions to Enable a Series of Level 4 to Level 3 to Support a Specific Business Process Scenario – Production Planning & Scheduling..................19 Figure 2-11: Example of P&G B2MML Application in B2M System Architecture ......................20 Figure 2-12: OAGIS Scope...........................................................................................................22 Figure 2-13: Example OAGIS Integration Scenario.....................................................................22 Figure 2-14: Standard OAGIS BOD Structure..............................................................................23 Figure 2-15: IBM EIMS - Current State: Customer Interfaces.....................................................25 Figure 2-16: IBM EIMS - Target State: Canonical Format and Framework...............................25 Figure 2-17: Order Management and Order Status Message Interactions Scenario...................26 Figure 2-18: EIMS Canonical Model – Reuse Methodology and Assets......................................27 Figure 2-19: OAGIS "Vendor Managed Inventory (Consumption) Scenario"..............................28 Figure 2-20: OAGIS "Production to Manufacturing Execution" Scenario..................................29 © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 4
    • Comparison of ISA-95 and OAGIS Figure 2-21: Ford UpdateVehicleOrderStatus BOD, based on OAGIS UpdateWIPConfirm.......30 Figure 2-22: OAGIS Extensibility – Accommodating Multiple Parties within a Vertical.............37 Figure 2-23: Overlay Extensions to the OAGIS............................................................................37 © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 5
    • Comparison of ISA-95 and OAGIS Overview Manufacturing organizations attempting to integrate the plant floor with ERP, supply chain, scheduling, quality and other systems in their enterprises today have difficult choices to make to base that integration on standards – specifically, what standard to choose. Unfortunately (or maybe fortunately, depending on your point of view) there are several choices available, all of which have strengths and weaknesses, and all of which overlap to some extent. The purpose of this paper is to compare two prominent standards for integrating applications (or, in today’s vernacular, for implementing composite applications based on services-oriented architecture (SOA): 1. OAGIS1 (current version 9.0) or Open Applications Group Integration Specification from the Open Applications Group Incorported (OAGi, www.openapplications.org) 2. ISA-95, Enterprise-Control System Integration Standard, from ISA1, (www.isa.org). This comparison paper is White Paper #1 of the ISA-95/OAGIS Manufacturing Integration Standards White Paper Series. White Paper #2, OAGIS, ISA-95 and Related Manufacturing Integration Standards, A Survey, explains the related standards that overlap or work in conjunction with ISA-95 and OAGIS in developing manufacturing system architectures. White Paper #3, Possible Convergence Directions for ISA-95 and OAGIS, presents a convergence path and alternatives for manufacturers currently constructing application integration architectures and for standards committees and working groups working through convergence discussions. In comparing ISA-95 and OAGIS, the paper first provides a brief history and structure of each standard and then presents a detailed comparison by noting the areas of overlap, non-overlap, and benefits. This paper is intended to provide a reference point for manufacturers developing their application integration methods and for standards groups going through the analysis necessary to make convergence decisions. A Common Vision The goal of both OAGIS and ISA-95 is to provide a more cost-effective way for organizations to integrate their applications with each other, with third party applications and with applications belonging to other organizations (e.g. suppliers). As a common point in both standards, the vision is to go beyond simply providing technology that facilitates integration (e.g. XML, messaging, web services) to establishing a common canonical standard for information to be exchanged between those applications, as well as a standard way of “packaging” that information. Note: In this comparison, a canonical standard for application information exchange is a corporate set of common nouns, verbs, message and application structures, and design rules for IT and manufacturing automation systems to allow simple forms to be exchanged while representing a full and complete meaning of the information to enable system integration and business knowledge management. Both ISA-95 and OAGIS are primarily focused on the content to be exchanged, not the mechanism (e.g. web services, messaging, FTP) by which the information is exchanged. Both attempt to encapsulate the application playing a role in an integration scenario (e.g., ERP supplying production orders to the plant floor) as a black box with information flowing in and 1 All trademarks are denoted with this footnote and listed in the Trademarks section at the end of this paper, before the references. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 6
    • Comparison of ISA-95 and OAGIS out of the black box based on the standard. Thus, information is transformed to a standard format as it passes through an interface that implements the canonical integration standard, before it is delivered to receiving applications. This substantially reduces integration efforts while increasing data accuracy. Using a common canonical standard message interface should reduce the interface development complexity by reducing the number of required interfaces from 2*N(N-1) to 2*N as seen in Figure 2-1, where N is the number of participating applications. If fully realized and adopted by an organization and its application vendors and suppliers, a convergent implementation of the OAGIS and the ISA-95 specifications (combined with consistent use of flexible integration infrastructure) would enable “plug and play” of applications. Figure 2-1: Standards-Based Application Integration Presently, ISA-95 is being implemented in products and services that will drive the look and feel of twenty-first century plants and best practices for continuous improvement in manufacturing operations. OAGIS is the foundation for data exchange at a number of major manufacturing enterprises. Companies are recognizing that production work flows and data flows must be identified, streamlined, and optimized through Lean manufacturing and Six-Sigma techniques. Performance metrics and their cause/effect relationships (and tradeoffs) to work flow are being characterized and built into computerized systems. OAGIS and ISA-95 are the enabling tools. Once the production environment is characterized using OAGIS and ISA-95, manufacturing operations management (MOM) applications are better able to maintain and transform the optimized Lean manufacturing processes through better integrated systems. These standards reinforce the practice of Lean manufacturing and Six-Sigma techniques such as: © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 7
    • Comparison of ISA-95 and OAGIS • Standard work flow practices across MOM activities of production, quality, maintenance, & inventory operations o Examples: Schedule/dispatch, data entry methods, CID, ECO, route definition. • Cross-training operators and mechanics: common work definition: operations and resources • A single production canonical schema across all Level 3 MOM applications simplifies interfaces and data exchanges • The common ISA-95 definition of a work unit (segment) and associated flows and their resources “Leans out” business processes, such as: o Single piece flow, line balancing and throughput o Analytics, reporting, alarm & event handling o Shop loading, scheduling, & dispatching o Method comparisons of activities and work o Standard costing or activity-based costing metrics o Labor performance measurement and control o Manpower and production requirements o Simplified standard design & planning methods for product, manufacturing & quality o MOM architecture administration & project management The standards aggregate this production data into capacity, capability, inventory, order and equipment scheduling data for exchange with ERP, APS, CRM and SCM systems. The next generation tools based on OAGIS and ISA-95 will provide consistency and flexibility to an enterprise, even with heterogeneous systems. These tools interact in real-time within the supply chain to determine the actual speed a company is able to create new markets and move into them. They enable decision-making based on measurable and specific manufacturing constraints. As more cultures, languages, foods and fashion drive higher demand for niche and make-to-order products, companies need responsive supply chains and flexible plants that can produce timely, profitable production runs. ISA-95 Brief History of ISA-95 (AKA: IEC 62264) Performance-based management for production has been slow to move into practice due to the lack of accepted standards for work flow and missing standards for information exchange interfaces between enterprise business applications and manufacturing management applications. Starting with ISA-88, Batch Control, in 1986 and followed by ISA-95 in 1995, the ISA (www.isa.org) has been progressively addressing the required pieces to the integration puzzle. In particular, the ISA-95 standard has adopted: 1. A functional and physical model of an application hierarchy 2. Terminology for manufacturing operations management 3. Methodologies describing information exchanges within Level 3 and between Levels 3 and 4 4. A common data object model within Level 3 © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 8
    • Comparison of ISA-95 and OAGIS 5. An activity model for manufacturing operations management within Level 3 Until recent real-world applications of ISA-88 and ISA-95 by innovative manufacturers, industrial and enterprise software vendors had not responded effectively to customers’ demand for a lower ownership cost of their application-to-application (A2A) interfaces within the plant, as well as between the enterprise and the plant. The goal of integrated information flows across multiple applications has been difficult and expensive to realize for vendors and end-users alike. Most environments involve legacy systems with vendor-specific data models and terminology; they lack standards for common data schema, thus making interoperability across applications a very large task. Currently, the production management software market includes a large number of point solutions. Few companies focus yet on the entire plant-wide canonical model across their information application architecture, and some end-users have real business reasons to run heterogeneous applications. Consequently, mapping data (tags, forms, types, and frequency) between applications has been a root-cause problem with implementing integrated information flows across performance-based production management systems. When first approaching ISA-95, most end users ask, “Where do I start?” Let’s start with a little history. In 1988, Dr. Ted Williams of Purdue University began the 15-year process to develop the working solution for integrated manufacturing. The International Purdue Workshops on Industrial Computer Systems that he conducted produced the Purdue Reference Model for Computer Integrated Manufacturing, which became a foundation for the ISA-95 standardized data schema and functional work flow models. This work contributed to developing the current approved three parts of the ISA-95 Enterprise-Control System Integration standard over the last 10 years. The ISA-95 standard addresses the interface or exchange of data between enterprise systems (planning, master scheduling, and procurement) and manufacturing operations management (MOM) systems (detailed work scheduling, dispatching, and execution). WBF, Inc. the Forum for Automation and Manufacturing Professionals (www.wbf.org) developed the Business-to-Manufacturing-Markup-Language (B2MML) following approval of ISA-95 Parts 1 and 2. B2MML is being developed separately from the SP95 committee due to the following: • XML (Extensible Markup Language) was a new technology (circa 1999-2001) which required experimentation by developers where quick releases would be needed. Like HTML, XML can be considered a derivative of SGML (ISO 8879), an international standard, and at the outset, it was not ready for international standardization. • B2MML was and is viewed as a “technology dependent implementation” of the ISA-95 standard. In the future, new technology will be developed where people may want to develop a newer implementation. The SP95 committee worked hard to make ISA-95 technology independent so it did not need to be tied to one technology (e.g. XML). The B2MML schemas, from the WBF’s XML working group, have matured and are being incorporated into industrial and enterprise software products. Some software vendors such as GE Fanuc®1 and Rockwell Automation®1 have implemented a common component framework across their respective MOM products to create a common data model based on the terminology, object models, and XML schema described in the ISA-88 and ISA-95 specifications. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 9
    • Comparison of ISA-95 and OAGIS ISA-95 is quickly becoming the tool for expressing application requirements between corporate cultures and departments: production, corporate IT, business analysts, maintenance, procurement, quality, etc. Each corporate area has its specific terminology and is now able to use ISA-95 to translate between the areas through a common baseline. The ISA-95 definitions and models assist in organizing disparate application requirements into a manufacturing application framework based on developing ISA-95 best practice methods and technical applications. Today, the basic use of ISA-95 within a manufacturing company is to characterize the internal and external process flows (data flows, schema, and work flow use cases) between the production and enterprise areas. This mapping is typically very difficult. In today’s typical application, the organizational structure of most companies does not reflect the generic ISA-95 functional and object models to any high degree. This is intentional. Business processes and MOM work flows vary dramatically across companies as they depend on the type of industry, process type (batch, discrete, continuous), or the production type (make-to-stock, make-to-order, engineer-to-order, mix ratio). The ISA-95 functional and object models are a good starting point for conducting the necessary baseline analysis of a company’s specific process flows. ISA-95 is intended to simply help to communicate data elements and requirements. Having a starting point is a huge benefit compared to the previous disparate situation. The ISA-95 models and terminology provide the required descriptive tools for production, corporate IT and business analysts to jointly develop integrated systems that truly characterize the work flow in an enterprise and to aggregate and distribute plant work data into MOM and enterprise systems. ISA-95 is changing manufacturing best practices through these advancements. Description of ISA-95 Structure Parts 1 and 2, Models and Terminology: 1. Boundaries are defined for information exchange between functional domain levels within an enterprise’s application hierarchy, with focus on the boundary between Level 4, the enterprise business level and Level 3, the plant floor or manufacturing operations management system level. Examples of domains and the types of information handled, including the time frames involved, are shown in Figure 2-2. 2. A physical (equipment or work resource) hierarchy is defined that structures the functional domain levels into an application hierarchy within an enterprise. In Figure 2-3, each level in a physical hierarchy is associated with the notion of an equipment (or work resource) entity that includes elements of work procedures and associated required resources. Although ISA-95 does not detail the entities below a work unit level, the reader is reminded that the types of equipment, work and resources differ across various industries and production process types. In most cases, the activities and functions at Level 3 are concerned with management of the resources and work performed by the work centers. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 10
    • Comparison of ISA-95 and OAGIS 4- Establishes the basic plant schedule - Business Planning production, material use, delivery, and Level 4 & Logistics shipping. Determines inventory levels. Plant Production Scheduling, Time Frame Operations Management, etc Months, weeks, days ISA-95.01, .02, & .05 Standards 3- Work unit defined. Work flow/recipe ISA-95.03, Manufacturing control produces desired end products. Level& .06 .04 3 Operations Management Analyzes work data, maintains records and Standards Dispatching Production, Detailed optimizes the production process. Production Time Frame Scheduling, Reliability Days, Shifts, hours, minutes, seconds 2- Work unit (operation): Monitor, Level 2 Contin- supervisory control and automated control of Batch Discrete uous Control Control the production work process. Control Level 1 1- Sensing of production work process, manipulate the production work process. Level 0 0- The actual production work ANSI/ISA-95.00.01 Copyright © 2006 ISA. Used with permission. www.isa.org process Figure 2-2: ISA-95 Domain Hierarchy from Purdue Reference Model Figure 2-3: ISA-95 Physical (Work / Resource) Hierarchy ANSI/ISA-95 Copyright © 2006 ISA. Used with permission. www.isa.org © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 11
    • Comparison of ISA-95 and OAGIS 3. Data flows of interest are defined that support MOM in exchanges between the Level 4 applications and the Level 3 applications; In Figure 2-4, the schematic diagram illustrates the activities (“bubbles” or circles) within the functional (or application) domains at the various levels of the hierarchy. The lines connecting the “bubbles” represent the information flows between the functions (resources) involved in these activities. Specific types of Information Categories (objects) are defined for MOM data flows of interest that are exchanged between Level 4 and Level 3 applications. Figure 2-5 illustrates that all the “Data Flows of Interest” fall into one of these Information Categories. Activities within Business Domain Information Flows of Interest Activity defined in Part 3 (e.g. Production Scheduling) (e.g. Production Schedule) Activity not defined in Part 3 Enterprise / Mfg. Operations Mgt. Level 4 Data flows defined in Part Boundary 1 and Part 2 Level 3 Data flows not mentioned Activities Within Mfg. Operations Mgt. Part 3 Information Flows Domain (e.g. Production Dispatching) Mfg. Operations Mgt. / Level 2 Process Control System Boundary Figure 2-4: ISA-95 Data Flows of Interest Supporting Manufacturing Operations Management and Exchanges between Levels 3 and 4 ANSI/ISA-95 Copyright © 2006 ISA. Used with permission. www.isa.org 4. Object models are defined to construct the ISA-95 Data Model that results in applications similar to the WBF’s B2MML schemas. The object models of 4 resource schemas (Personnel, Material, Equipment, and Process Segment) are used to construct the 4 MOM Information Category Schemas (Product Definition, Capability, Schedule, and Production Performance). The resource object models construct a “segment” or unit of work, which is the ISA-95 generic term for an operation, step or phase. The process segment is the foundation concept of the ISA-95 data model that allows Level 2 real-time data to be contextualized and aggregated for business process activities. Level 2 data is aggregated by resource objects to and from the Information Category objects shown in Figure 2-5. The derived Product Definition and Production Schedule object models use this data structure for scheduling, dispatching and execution applications to contextualize Level 4 business process information into a form required for Level 2 and Level 3 MOM (Part 3) applications. The derived Production Performance and Capability object models use this data structure to contextualize real-time data in data collection applications so that analytics, tracking, reporting and Level 3-4 interface applications are easily able to aggregate Level 2 and Level 3 applications into a form required for Level 4 applications. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 12
    • Comparison of ISA-95 and OAGIS A segment in a recipe or production route is constructed by using the combined resource models (personnel, equipment, and materials) in unison to describe the unit of work in terms of resources and resource test requirements. Level 4: Business Planning & Logistics Information Plant production scheduling, operational management, etc Product Production Production Production Definition Capability Schedule Performance Information Information Information Information (What must be (What (What actual (What actual defined to resources production will production was make a are available) be executed) achieved) product) Level 3: Manufacturing Operations Management Information Operations Management: Production, Maintenance, Quality Test, Inventory Figure 2-5: ISA-95 Information Categories (objects) Handled by Manufacturing Operations Management and Exchanged between Levels 3 and 4 ANSI/ISA-95 Copyright © 2006 ISA. Used with permission. www.isa.org For example, each person in a plant gets identification (ID) and a set of personnel classes whose specifications are tested prior to permitting the person to being scheduled, dispatched, or executed as a resource in a segment or operation. Personnel are tracked from Level 2 and analyzed at Level 3 based on this ID and property class within the segment. Process segments are used to construct a library of plant capabilities that are used to generate “Product Segments” for actual products, which have the form of production routes in discrete hybrid environments or recipes in batch-process hybrid environments (See Table 2-1). ISA-95 has different increasing levels of granularity for the product segment definition for each Level 3 activity function (Schedule, Dispatch, & Execution). The benefit is that the actual application outputs are contextualized in a form needed for each function’s specific interface. When each Level 3 application’s results and Level 2 work data are fed back to Level 3 Data Collection applications in the contextualized form, the Production Performance applications (analysis, tracking, reporting and interfacing) can readily aggregate the information for the Production Order as facilitated by the ISA-95 data model and segment concept. This segment construction is the basis for the four information areas of Production Performance. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 13
    • Comparison of ISA-95 and OAGIS Each Product Segment Has Process Segment Reference • When Product Segment is contained in the Production Schedule schema in the Detailed Scheduling application (Figure 2-7), it is typically applied at a macro level as a single Product Segment. It typically contains the entire Bill of Resources to produce the Production (order) Request coming from a Level 4 ERP. • As the Production Request is then moved to a Dispatching application, the Product Segment must become a more granular definition of the production route/recipe. In Dispatching, each operation, procedure or step is defined by a detailed Product Segment so each resource is able to be dispatched for Execution in proper time sequence. • As the Production Request is forwarded to the Execution application, the Product Segments from the dispatched route contain further definition by obtaining all the execution parameters and specifications from the Production Definition Management function or application. Table 2-1: ISA-95 Product Segment - Sample Forms In particular, Figure 2-6 shows an example of an ISA-95 class diagram for the Production Schedule information object, which is made up of several components, including the resources needed to accomplish the various Production Requests (or orders) to be completed. Production Schedule Is made up of 1..n Production Request Is made up of 1..n 0..n Segment Requested Requirement Segment Response May contain 0..n 0..n 0..n 0..n 0..n 0..n Material Material Production Personnel Equipment Consumable Produced Consumed Parameter Requirement Requirement Expected Requirement Requirement 1..n 1..n 1..n 1..n 1..n Personnel Equipment Material Material Consumable Requirement Requirement Produced Consumed Expected Property Property Requirement Requirement Property Property Property Figure 2-6: Example of ISA-95 Production Schedule Information Object Exchanged Between Level 4 and Level 3 ANSI/ISA-95 Copyright © 2006 ISA. Used with permission. www.isa.org © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 14
    • Comparison of ISA-95 and OAGIS Part 3, MOM Activity Models Part 3 defines the detailed activities of several MOM application categories and their interrelations (work flow) within Level 3 and as well as interactions with Level 4 applications. As shown in Figure 2-7, a generic detailed activity model is defined and used to elaborate four (4) key MOM activities: Production, Maintenance, Quality Testing, and Inventory handling. Functions and high level data exchanges are defined for each MOM activity. Operations Operations Operations Operations Level 4 (Work) Capability Request Response Definition (For Work) (Work Schedule) (Work Performance) Detailed Scheduling Level 3 Resource Management Tracking Generic activity Dispatching Analysis model for the following operation categories: Definition Data Production Management Collection Maintenance Execution Quality Testing Management Inventory Level 2 Work Activities Level 2 Figure 2-7: ISA-95 Generic Detailed Work Activity Model (Part 3) for MOM ANSI/ISA-95 Copyright © 2006 ISA. Used with permission. www.isa.org Each detailed function in an activity supports information exchanges with other functions and activities; however, not all possible information exchanges among these activities are included in the diagram. Part 4, MOM Activity Object Models and Attributes Part 4 of ISA-95 is in early draft stages and will define additional object models and attributes, based on those already defined in Part 2, to describe and organize the information exchanged between MOM functions defined in Part 3. These object models and attributes are intended to be used in the design and implementation of interface standards to enable interoperability within the MOM (Level 3) domain. Part 5, Business-to-Manufacturing (B2M) Transactions Part 5 of ISA-95 defines B2M transaction models and messaging structures formed from a subset of OAGIS verbs and ISA-95 nouns composed of the objects defined in Parts 1 and 2 of ISA-95. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 15
    • Comparison of ISA-95 and OAGIS The messages deal with both the scheduled manufacturing tasks and those actually performed. These message exchanges can occur at all levels within the enterprise, but the focus of Part 5 is on transactions involving messages that cross the interface between MOM Level 3 and the enterprise Level 4 systems. The defined transaction models are intended to provide visual tools for explaining the information flows and functional coordination between the business and manufacturing processes. An example transaction is shown in Figure 2-8. Application ID Area Information Information Provider GET Equipment VERB = GET User Data Area Noun = Equipment ID= “ABC” GET Local Application ID Area Processing VERB = SHOW Noun = Equipment SHOW Equipment ID= “ABC” Description Data Areaequipment” = “Simple Equipment Property ID = “Throughput” Value = 200 PPM Description = “Throughput as SHOW parts per minute” … Figure 2-8: Example of ISA-95/OAGIS Transaction Composed of Two Basic Messages, Each Formed by an OAGIS Verb- B2MML Noun Combination ISA-95 Copyright © 2006 ISA. Used with permission. www.isa.org Current Status Here is a brief listing of current efforts relating to ISA-95 and ISA-88: • 2004: ISA forms joint working group to harmonize related parts of ISA-88 and ISA-95. • 2005: Start work to update ANSI/ISA-95.00.01 and ANSI/ISA-95.00.02, Enterprise- Control System Integration Part 1 and Part 2 to include additions made to IEC 62264-1 and IEC 62264-2. • 2006 April: Manufacturing Interoperability Guideline Working Group (MIG WG) formed to develop a convergence approach for Level 4 / Level 3 transactions using ISA-95 and OAGIS. • 2006: SP88 WG1 formed to update ANSI/ISA-88.01, Batch Control Part 1: Models and Terminology, to reflect continuing alignment with other parts of ISA-88 and related parts in ISA-95. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 16
    • Comparison of ISA-95 and OAGIS • 2006 Sept: ISA-95.00.05, Enterprise-Control System Integration Part 5: Business to Manufacturing Transactions, Draft 10 released for publication. • 2006 Sept: CDV ballot closing for IEC 62264-3, Enterprise-Control System Integration - Part 3: Activity Models of Manufacturing Operations Management. • 2006 Nov: ISA-95.00.04, Enterprise-Control System Integration Part 4: Object Models and Attributes of Manufacturing Operations Management, Draft 3 released. Typical Application (examples) Most practical applications of ISA-95 to integrate business systems with manufacturing control systems involve the use of common process scenarios. Each scenario details the information exchanges that need to occur between the applications performing the required functions. Operations and financial metrics for process scenarios that accurately represent the manufacturing environment change with customer demand and a company’s profit requirements. The metric construction process starts by characterizing and benchmarking the supply chain and manufacturing process scenarios. The metrics construction requires an iterative process of a top- down and a bottom-up approach. The strategic top-down process identifies the metrics for work planning and logistics and maps their calculation to manufacturing (work) operations analytics, which, in turn, are aggregated from actual work execution and operations metrics. The tactical bottom-up process requires, first, that the basic unit of work for the production process and business process be defined and structured in an ISA-95 manufacturing operations data model. Six-sigma tools assist in determining the operation metrics and lower level financial metrics to combine for high level metrics. The ISA-95 manufacturing operations data model is used to structure data collection of the real- time operations metrics for operations analytics. This data model is the foundation for activity- based metrics for operations and costing. One purpose of the ISA-95 manufacturing operations data model is to enable aggregating production activity data into the appropriate form for the planning and financial data models. Using six-sigma tools, the operations analytics convert large sets of parametric production data and real-time process data into activity performance and cost data. These resulting analytics data are inputs or data collections for the enterprise metrics for planning, logistics, and finance. They are also the foundation data model for supply chain management. In one common scenario, a set of customer orders are received by the business application and a Production Schedule is generated to manufacture a set of products for delivery by a certain time. As the business application sends the Production Schedule to the manufacturing production application, the anticipated Production Capability is verified and the Production Schedule is modified accordingly. The updated Production Schedule is received by the plant floor applications and the detailed Production Requests are performed. As the Production Schedule is being completed, a series of Production Performance reports are sent by the plant floor applications to the business applications, which are tracking the completion of the customer orders for delivery. The transactions typically generated in such a scenario are modeled in a sequence diagram as shown in Figure 2-9. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 17
    • Comparison of ISA-95 and OAGIS A push/pull transaction model is used in the transactions to indicate a simple request-response sequence of messages between a business application and a plant floor application. A different transaction model could have been used where a business application “publisher” transacts with several “subscriber” plant floor applications. Production Schedule Changes using Production Capability as Input (Push/Pull Model) ERP MOM Level 4 PROCESS – Production Schedule Level 3 Production PROCESS – Production Performance Some work Scheduling complete GET – Production Capability SHOW – Production Capability Schedule CHANGE – Production Schedule Some more changes work complete PROCESS – Production Performance All work PROCESS – Production Performance finished Scenario assumptions: 1. ERP sends production schedule to MOM for processing 2. MOM sends production performance to ERP for processing 3. ERP requests production capability from MOM 4. MOM sends production capability to ERP 5. ERP makes change to schedule and sends to MOM for processing 6. MOM sends production performance to ERP reflecting partial order completion 7. MOM sends production performance to ERP reflecting completion of order Figure 2-9: Example of a Sequence of ISA-95 Transactions to Enable a Specific Business Process Scenario – Production Schedule Changes Based on Production Capability Input ISA-95 Copyright © 2006 ISA. Used with permission. www.isa.org In another example, other manufacturing operations management functions can be included in these scenarios. In Figure 2-10, a more complete production planning and scheduling scenario can include both asset maintenance schedules and material movement schedules. The Level 4 advanced planning applications can use the additional information provided by the Level 3 applications to perform the necessary scheduling calculations to generate a more comprehensive manufacturing schedule (i.e. for production, maintenance, product quality assurance testing, and inventory movement and allocations). Detailed operating schedules for each of these plant floor applications (Level 3) result in periodic reports to corresponding Level 4 applications, such as, asset management, quality assurance, inventory, and logistics. More complete and detailed scenarios for actual applications can be built by composing smaller but well-bounded scenarios. Transactions among the various component scenarios have a critical © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 18
    • Comparison of ISA-95 and OAGIS path and use the OAGIS/ISA-95 transaction models to describe the required information exchanges between the target applications at both Levels 4 and 3. Production Planning & Scheduling Scenario Level 4 Level 4 Level 4 Production Planning Level 4 PLM Asset Mgt & Capability Analysis Inventory Mgt Producti Definitio Product Capabili PROCE SHOW SS PROCE Product on ty n Perfor mance pmen SHO Equi ion SS W t Product Definiti GET on Mater CESS SubL PRO Equip ial ot ment GET Schedu Produc PROC ESS tion le Level 3 Level 3 Level 3 Level 3 Product Production Detailed Production Definition Resource Mgt Scheduling Tracking Management Figure 2-10: Example of Set of ISA-95 Transactions to Enable a Series of Level 4 to Level 3 to Support a Specific Business Process Scenario – Production Planning & Scheduling ISA-95 Copyright © 2006 ISA. Used with permission. www.isa.org In order to provide a full description of the information flow to enable the business-to-plant floor integration goal of ISA-95, the ISA-88 plant control activities and the flow of data objects originating from and directed to Level 2 and below are coordinated with the corresponding ISA-95 activities and information object flows. In an important evolving implementation of ISA-95, the WBF, the Forum for Automation and Manufacturing Professionals (www.wbf.org), has implemented XML schemas for the data object models defined in Parts 1 and 2 of ISA-95. The set of XML schemas are provided in the B2MML (Business-to-Manufacturing Markup Language) specifications, which are currently at Version 3. In a real world example in Figure 2-11, Proctor & Gamble (P&G) applied ISA-95 throughout its corporate manufacturing operations architecture and applied a B2MML application to automate the ERP/MOM information exchanges. An ISA-95 production schedule for orders including a bill-of-materials (BOM) and the corresponding ISA-95 production performance for consumption of material and production resources including order confirmation are delivered through the interface. “P&G S95” is the basis for a corporate deployment of the S95 XML at P&G to more systems with more message types. “P&G S95” provides the interface layer between SAP messages and the B2MML files exchanged with other systems. An EAI middleware performs both the message translation and message routing functions. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 19
    • Comparison of ISA-95 and OAGIS Data Flow: Data Flow: Needed Components SAP to MES MES to SAP by Layer IDOC SAP sends Partner Profile and Variants SAP (Regional) IDOC to BC Database Scheduled Jobs and/or Manual Trigger Error Logging and Notification IDOC IDOC S95” “P& G An y ERP SAP Adapter (IDOC Listener) EAI Routing Rule (links IDOC to SAP BC SAP BC Business Receives Receives specific routing service) Connector Routing Service (Calls IDOC, XML, (Regional) appropriate transformation Transforms to Transforms to service and FTPs documents to XML, IDOC format, destination) Sends to MES Sends to SAP Transformation Service (between IDOC and XML) XML XML B2MML Document Document Directory structures for XML file Files received Builds: MES Interface handling via FTP DGR XML new MES SAP Download Server MOM B2MML production MES SAP Upload (per Process XML file DGI XML new Error Logging and Notification Plant/Dept) Inserts Order & consumption BOM into dbase Confirmation Move XML file to XML directory XML to BC FTP MOM An y MS SQL Server MES Server MES Service (such as FTP (per Database Database Service) Plant/Dept) Figure 2-11: Example of P&G B2MML Application in B2M System Architecture WBF Copyright © 2006. Used with permission. www.wbf.org © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 20
    • Comparison of ISA-95 and OAGIS OAGIS Brief History of OAGIS1 The Open Applications Group is a not-for-profit industry consortium focused on building a business-process-based data exchange model for enterprise functions. The Open Applications Group Integration Specification, OAGIS, is a standard, which, now on version 9.0, has been under development since 1994. In 1995, the Open Applications Group, Inc (OAGi) industry consortium was formed consisting initially of eight ERP vendors: American Software®1, CODA Financials®1, Dun&Bradstreet®1 Software, Marcam, Oracle®1, PeopleSoft®1, SAP®1 and Software 2000®1. Today the membership of the Open Applications Group comes from end-user companies, government agencies, and solution providers. OAGIS was created as the first post-EDI data exchange data model. It is intended to provide a more flexible way of solving the same business-to-business (B2B) and application-to-application (A2A) integration problem (shown in Figure 2-1) that EDI addressed in the past. In their early years, members invented their own meta language for programming data exchange interfaces. When XML was established by the W3C in 1998, OAGIS was the first major data exchange standard to embrace it. OAGIS is built as a horizontal business language, enabling it to be used in many industries worldwide. The scope of OAGIS extends the enterprise’s reach across the organization – for A2A, down into the organization for enterprise application to execution (A2E) systems, and outside the organization for B2B functions. The scope of OAGIS is depicted below in Figure 2-12: • eCommerce • Logistics  e-Catalog  Orders  Price Lists  Shipments  RFQ and Quote  Routings • Order Management • CRM  Purchasing  Opportunities  Invoice  Sales Leads  Payments  Customer  Sales Force Automation • Manufacturing  MES • ERP  Shop Floor  Financials  Plant Data Collection  Human Resources  Engineering  Manufacturing  Warehouse Management  Credit Management  Enterprise Asset Management  Sarbanes/Oxley & Control © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 21
    • OAGIS® Scope The Enterprise A. To Extra-Enterprise Systems B. Between Enterprise Applications C. To Special Purpose Applications Figure 2-12: OAGIS Scope Description of OAGIS Structure OAGIS has approached the integration problem by first establishing integration scenarios for a set of applications. For example, ERP, Production planning, MES and Capacity analysis is shown in Figure 2-13. Figure 2-13: Example OAGIS Integration Scenario
    • Comparison of ISA-95 and OAGIS The flows shown between the applications, e.g. Sync ProductionOrder, consist of OAGIS Business Object Documents (BODs) that are defined as part of the standard. Each BOD has a standard structure with a standard header and a body that is unique to the BOD: Figure 2-14: Standard OAGIS BOD Structure OAGIS Release 9.0 contains 434 BODs that are reusable across integration scenarios and are constructed using reusable verbs (12) and nouns (77). As seen in the diagram, the nouns reduce to components, which in turn reduce to fields and compound structures. All of this is represented in a (free) downloadable XML schema; corresponding WSDL files are available as well. The entire OAGIS standard is available today as a free download to anyone who registers on the Web site. Current Status As of June 2006, OAGi has over 35 members. Version 9.0 of the OAGIS standard claims full support for the UN/CEFACT/ISO Core Components technical specification, CCTS 2.01, harmonized core components from UN/CEFACT TBG17 the United Nations Centre for Trade Facilitation and Electronic Business. The core components work is important because it is, essentially, an attempt to develop a standardized set of building blocks for common components (e.g., “person”) that can then be used to standardize definitions across standards bodies. One of the first points of agreement between OAGi, ISA, and the other groups involved in the Manufacturing Interoperability Guidelines working group was to use core components as a starting point for convergence. OAGi is also contributing to the UN/CEFACT core components work (as are users of OAGIS such as AIAG). OAGIS is used today in at least 40 industries in over 40 countries. In December 2005, OAGi and ISA announced its intent to converge the OAGIS and ISA-95 standards. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 23
    • Comparison of ISA-95 and OAGIS Typical Application (examples) The following are two examples of how OAGIS is being used in “real life” system architectures: Example: IBM EIMS IBM1 adopted OAGIS internally in 2004 as the basis for its corporate messaging standard and is extending the standard to meet its needs by creating an “Enterprise Integration Messaging Specification (EIMS).” The initiative was prompted by a challenge from IBM’s CIO to “transform IBM to an on-demand enterprise that can quickly deliver business value through increased productivity and automation (using services-oriented architecture (SOA) approaches and open standards). Given that challenge, the EIMS messaging architecture was established and is now being rolled out within the company. The objectives of the EIMS messaging architecture (depicted in Figure 2-15 below) are: • Loose coupling - Service application interfaces are specified and managed in a manner that allows service functions to be loosely coupled, location transparent, and protocol independent. • Application re-engineering - Support the evolution of IBM’s internal application landscape from one that encompasses a large number of proprietary solutions (4800+), to a more flexible and resilient architecture, with significantly less redundancy. • Common business data representation - Existing applications/components are leveraged to provide their services using a “common business data representation.” Existing functions are “represented” using common data vocabularies, so that the services provided by these functions can be available to the enterprise in a consistent way, regardless of its existing proprietary interface. • Integration simplification - SOA applications are integrated at the service specification point, not at the application interface. This allows application complexities to be isolated from the services interface, and minimizes the impacts of back-end interface and application changes. • Responsiveness to change - Provides an environment whereby business services work flow and business process re-orchestration can be accomplished easily, without the need to go through costly and time consuming software development cycles; (i.e., changes may be made by a business analyst, rather than by a developer). © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 24
    • Comparison of ISA-95 and OAGIS Figure 2-15: IBM EIMS - Current State: Customer Interfaces Figure 2-16: IBM EIMS - Target State: Canonical Format and Framework © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 25
    • Comparison of ISA-95 and OAGIS Like many users of OAGIS, IBM is using the standard more as a framework for creating an extended message set that meets IBM’s needs and is not just using OAGIS “as is” off the shelf. What changes is IBM making? To begin with, new integration scenarios are being defined that use existing OAGIS BODs in conjunction with some “new” BODs (defined by IBM using OAGIS “building blocks” such as the Verbs and Nouns). For example, Figure 2-17 is a new scenario created by IBM to handle business processes not covered by existing scenarios in the OAGIS specification. The scenario uses existing OAGIS BODs in conjunction with two new BODS (GetOrderStatus, ShowOrderStatus) defined by IBM. ProcessPurchaseOrder Internal Order ShowPurchaseOrder Order Order Submitters Manager (e.g., CCE) ProcessPurchaseOrder (No Ack) Fulfillment Applications External (B2B) ShowPurchaseOrder Order Submitters (E2Open, PCS) OrderStatus, (Includes any changes GetOrderStatus (Future) In Order Item Schedule, Pricing, Order Configuration, Delivery etc.) ShowOrderStatus (Future) Status Figure 2-17: Order Management and Order Status Message Interactions Scenario How are the new BODs defined? The approach IBM uses is shown in Figure 2-18. Essentially, IBM is using OAG as a toolkit of BOD building parts (verbs, nouns, fields) that can be used to create new BODs or extend existing BODs, to meet the company’s integration needs. As part of this work, IBM has created 40+ new BODs, 20+ new nouns and no new verbs. The resulting EIMS is then a combination of the XML specification covered by the OAGIS namespace and the extensions in the Integration Messaging Specification (IMS) namespace (this is a typical means of extending the “off the shelf” specification). One key benefit for any company applying OAGIS or ISA-95 is its internal canonical business architecture (schema and message structure) is established based on its particular business model. Further, the architecture has a documented method for extension; it is common and extended components are documented. This enables a company to easily construct and quickly reconcile its business-to-business (B2B) transaction scenarios and interfaces with partner companies that also have adopted an OAGIS/ISA-95 based SOA. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 26
    • Comparison of ISA-95 and OAGIS Figure 2-18: EIMS Canonical Model – Reuse Methodology and Assets Example: Ford Motor Company Ford®1 has been using OAGIS in production for plant applications for about five years. At this point, Ford is now using OAGIS in at least 24 plants in North America and Europe in conjunction with its “eHub/eSpoke” infrastructure (for more on this, see the excellent paper on XML Excellence at Ford Motor Company listed in the references). Briefly stated, the Ford eHub is an integration hub used so internal Ford applications directly communicate with suppliers securely, using web services/XML). In production, Ford Motor Company focused on two different scenarios: 1. Consumption Reporting Ford is using the OAGIS “Show Consumption” BOD to report materials consumption to suppliers (from the OAGIS “Vendor Managed Inventory (Consumption) Scenario” shown in Figure 2-19. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 27
    • Comparison of ISA-95 and OAGIS Figure 2-19: OAGIS "Vendor Managed Inventory (Consumption) Scenario" 2. Production Status Reporting Ford is using the “Show WIP Status” BOD from the OAGIS “Production to Manufacturing Execution” scenario shown in Figure 2-20 to report production status from plant floor to business applications. Ford’s application of OAGIS is flattened somewhat and simplified for plant floor usage, so production BODs are more lightweight and easier to work with from a tools and mapping perspective. This demonstrates the extensibility of OAGIS. Ford is, at the moment, using OAGIS in the following manner: 1. Ford used OAGIS integration scenarios and selected BODs per the standard, as previously described for application (and supplier) integration. 2. It uses OAGIS as a messaging toolkit to build simplified versions of OAGIS BODs for use in its plant floor environment. (Ford chose a BOD, and created a pared-down version of it with a simpler, flatter structure more focused on automotive manufacturing). © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 28
    • Comparison of ISA-95 and OAGIS Figure 2-20: OAGIS "Production to Manufacturing Execution" Scenario As an example of an automotive-focused BOD created by Ford, the next figure illustrates the communicating vehicle production status from the plant floor to enterprise applications (this Ford-created BOD is based on the OAGIS “UpdateConfirmWIP” BOD). If you wish to see the OAGIS version of this BOD (not included here for brevity), it is in the downloadable (www.openapplications.org) OAGIS Version 9.0 documentation under “…ReferencesGeneratedBODInstances”, file UpdateConfirmWIP.xml. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 29
    • Comparison of ISA-95 and OAGIS Figure 2-21: Ford UpdateVehicleOrderStatus BOD, based on OAGIS UpdateWIPConfirm © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 30
    • Comparison of ISA-95 and OAGIS ISA-95 OAGIS Comparison The following table summarizes differences between the ISA-95 and OAGIS standards in some key areas covered in this paper: Attribute OAGIS ISA-95 / ISA-88 Focus OAGIS focuses on the entire data ISA-95 focuses on integrating business exchange problem domain, not just (Level 4) and plant (Level 3) operations manufacturing functions and domains and throughout plant operations, processes. This includes and models Level 3. Data exchanges are Application-to-Application (A2A), defined for the domains using models for Business-to-Business (B2B), and activities, related functions and what they call A2E, for information objects. ISA-95 defines a application-to-execution systems, hierarchical approach to organizing data such as manufacturing or exchanged between Levels 3 and 4. warehouse management. The Resulting applications aggregate work standard includes business process process data into the form of operations definitions called Scenarios and and business metrics. A supporting Business Object Definitions standard, ISA-88, focuses on work process (BODs), which are messages used integration at plant floor domain, in to accomplish the scenarios. particular, within the control and OAGIS also contains a automation work centers. sophisticated application meta model for documents, a messaging model, a context model, and an object model for re-using components used to build BODs. Data Model OAGIS is focused on the data ISA-95 provides a model of data objects model for data exchange, not for applications expressible in XML really for full enterprise objects. schemas, and exchanged between OAGIS uses XML to provide applications to coordinate MOM activities. developers with a machine- Using this ISA-95 data model, Level 3 readable version of the data operations analytics covert large sets of exchange data model. parametric production data and real-time process data into activity performance and cost data. These resulting analytics are mapped into Level 4 data collections for the enterprise metrics for planning, logistics, and financial. Messaging The OAGIS BOD Message Part 5 of ISA-95 defines a simple Support Architecture is independent of any messaging scheme between data object transport/communication “owners” and “users”; each “message” mechanism. Each BOD contains consists of an OAGIS “verb” and an one unique ApplicationArea which ISA-95 “noun”; each ISA-95 “noun” can be used to convey consists of one or more ISA-95 data © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 31
    • Comparison of ISA-95 and OAGIS communication information at the objects defined in Part 2; An ISA-95 application/integration layer. “transaction” is made up of several “messages” exchanged among two or more applications. Extensibility As different industries have Using object properties in Parts 1 and 2, different needs, OAGIS must be implementations such as B2MML use extensible in order to allow extension capabilities of ISA-95 properties industry verticals to plug in through the use extension schemas. Data information needed in their object “property” class qualifiers are used industry. For this reason the BODs to extend the set of object attributes, in have been designed to be addition to new “nouns”; while verbs are extensible, while providing a qualified further by “wildcards.” common architecture and content Part 3 of ISA-95 provides a generic for integration. OAGIS provides activity model for the manufacturing both User Area Extensibility and operations management application Overlay Extexsibility. UserArea domain; Components of “nouns” are the Extensibility: If additional content data models that are industry-generic and is required, each noun and domain-independent; Part 4 will provide component contains a UserArea additional nouns needed for dealing with component, which is intended to the other MOM categories. contain the additional content. The UserArea allows adding optional fields in every OAGIS component. Overlay extensibility provides a means of layering industry/vertical-specific vocabularies on the OAGIS base Vendor Implementations using OAGIS Providers of ISA-95 based Support come from solution providers in implementations are mostly industrial the business domains pertaining to automation system suppliers and plant enterprise resource planning, floor system integrators of manufacturing customer relationship execution, automation, and control management, logistics support, solutions. and other Level 4 oriented An increasing number of global industrial functions, as well as from automation industry suppliers and suppliers of MES systems. integrators are offering products and services. Active Because the OAGIS specification Solution providers and companies involved Applications is available for free download in food, life sciences, automotive, beverage (untracked), it is difficult to say currently. Other industries are following, how many implementations now such as, oil & gas, chemical, aerospace and exist. The specification has been pulp & paper. downloaded over one hundred thousand times. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 32
    • Comparison of ISA-95 and OAGIS OAGi does know of over 200,000 business connections using OAGIS and perhaps over 1,000,000 in over 40 countries worldwide. Some of the largest users include IBM, Microsoft1, Cisco Systems1, Ford, Boeing®1, General Motors®1, GE®1, the U.S. Air Force and many others. Cost Specification is free, consultation Free download of B2MML available at is available from OAGi for a fee www.wbf.org (www.openapplications.org). ISA standards series cost $299.00 (www.isa.org); it includes ANSI/ISA-95.00.01-2000, Enterprise- Control System Integration Part 1: Models and Terminology; ANSI/ISA-95.00.02-2001, Enterprise- Control System Integration Part 2: Object Model Attributes; ANSI/ISA-95.00.03-2005, Enterprise- Control System Integration, Part 3: Models of Manufacturing Operations Management. 7 ISA Technical Papers on manufacturing execution systems are available. Part 4 and 5 are in draft and available for free at ISA-95 section of ISA site. IEC versions are available from IEC. Data Model Comparison The OAGIS data model is encapsulated within the XML Schemas it ships, but in earlier releases it was not documented separately. OAGIS 9.1, due out in the first quarter of 2007, will contain a UML depiction of the OAGIS data exchange data model, and it will be freely downloadable at that time. The OAGIS data model focuses on the enterprise functions such as Production Order, Customer, Invoice, Purchase Order, Payment, etc. See the OAGIS site for more details: http://www.openapplications.org/downloads/oagidownloads.htm ISA-95 defines and documents a data model (see ISA-95, Part 2), but doesn’t incorporate XML Schemas. Separately, schemas implementing ISA-95 have been created in XML (see B2MML) by the WBF organization. Additional data objects for the other manufacturing operations categories (i.e. maintenance, quality assurance testing, and inventory movements) will be defined in Part 4. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 33
    • Comparison of ISA-95 and OAGIS A key difference is ISA-95 standards are built around set of models developed by consensus of participating contributors that are independent of technology. It offers a hierarchical approach to the data model. OAGIS is a broad, complex, and exhaustive standard that encompasses many use cases. It evolved is an XML implementation of interfaces that were developed as needs were identified without reference to a documented model, as use cases were incorporated into the standard through a rigorous process. The ISA-95 object models and resulting B2MML schemas are based on constructing a “segment” (unit of work, which is the ISA-95 term for an operation. It is the foundation concept of the ISA-95 data model. A segment in a recipe or production route is constructed by using the personnel, equipment, and materials models in unison to describe the unit of work in terms of resources and resource test requirements. For example, each person in a plant gets an ID and a set of personnel classes whose qualifications are tested prior to being permitted to be scheduled, dispatched, or executed as a segment or operation. Personnel are tracked and analyzed based on this ID and property class within the segment. This object model of four resource schemas (personnel, material, equipment and process segment) are used to construct the four Production Management Information Schemas of: Product Definition, Schedule, Capability and Performance. Please refer to the earlier section, Description of ISA-95 Structure, Parts 1 and 2 Models and Terminology (Bullet 4), for a detailed explanation of the relationship of Product Segments and corresponding Product Segments for Level 2 to 3 and Level 3 to 4 data aggregation for reporting, analytics, and interface configuration. Below are URLs for more information about the data models. http://www.isa.org/MSTemplate.cfm?MicrositeID=285&CommitteeID=4747 http://wbf.org/displaycommon.cfm?an=1&subarticlenbr=45 Messaging Support Comparison OAGIS Messaging Overview The OAGIS BOD Message Architecture is independent of any transport/communication mechanism. Each BOD consists of the seven areas shown in Figure 2-14: • One unique Application Area which can be used to convey communication information at the application/integration layer. • A Data Area containing the business specific payload. • A Noun to identify the business data contained within the Data Area. • A Verb to identify the action to be performed on the Noun. • Components are extensible building blocks of a Noun. • Compounds are the building blocks that are shared across all BODs. • Fields are the base elements that are used to build Compounds and Components. For a more detailed description of the areas that make up an OAGIS BOD, please refer to the OAGIS website: http://www.openapplications.org. Depending on the implementation/infrastructure, the BOD name (verb/noun) along with any one of the fields or a combination of the fields contained in the Application Area can be used to determine message source and routing information. For example, in a Java Message Service © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 34
    • Comparison of ISA-95 and OAGIS (JMS)-based infrastructure, the fields contained in the Application Area can be used to look up the Queue/Topic Connection Factory information. The presence of these fields within the BOD provides flexibility to control the delivery of messages by the application, by the infrastructure, or a combination of both. Receiver information is not conveyed in the BOD structure, since any BOD may be routed to multiple destinations. This routing is best left to the infrastructure to insure that all intended destinations receive the appropriate BODs. ISA-95 Messaging Overview [Also see Figure 2-8 and text pertaining to contents of ISA-95 Part 5.] The ISA-95 messaging scheme is also independent of any transport communication technology, platform, or product. However, a set of transaction models is assumed to be realizable. These transaction models include a Pull model for query and reporting, a Push model for task processing and a Publish model for data synchronization. In all the ISA-95 transaction models, a transaction consists of one or more ISA-95 messages and an ISA-95 message represent a one- way transfer of some information. The basic structure of an ISA-95 message is similar to an OAGIS message. It consists of two (2) main areas – an Application Area used to manage information about the corresponding applications and any related information about the veracity and chronology of the message, and a Data Area used to carry the “verb” and the “noun” of the message. As noted earlier in this document, the ISA-95 set of “verbs” are identical to the OAGIS “verbs” where the names used and the actions defined on the “noun” sent along with the “verb” in a message are the same. However, only subsets of the OAGIS “verbs” are used in the ISA-95 specifications. On the other hand, the ISA-95 “nouns” are composed of the data objects defined in ISA-95 Part 2, and the specific combinations are defined in ISA-95 Part 5. Further the use of wildcards in the “noun” ID notation allows references to multiple “nouns” in a single message. Extensibility Comparison OAGIS and ISA-95 are said to be horizontal standards with a defined set of industry independent information. Extensibility of these standards is necessary to incorporate content to satisfy the needs of the vertical industries (automotive, aerospace, food, electronics, etc.) as well as specific integration/application needs of an individual company’s business model and subsequent system architecture. OAGIS Extensibility OAGIS uses a standard set of nouns, components, compounds (complex types) and fields (simple types), which are industry independent. The use of each component, compound, and field is defined as being either required or optional, depending on the specific noun in which each is used. For typical business transactions, OAGIS has a broad base. Different industries, companies and organizations have their own set of vocabularies. OAGIS has been designed to accommodate these differences. Starting with OAGIS 8, there are two ways to add content to or extend a BOD: © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 35
    • Comparison of ISA-95 and OAGIS 1. UserArea Extensibility. When few additions are needed, it is recommended that a user add content to the appropriate UserArea component. 2. Overlay Extensibility. When extensive additions, or new BODs and/or components are needed, it is recommended that a user build Overlay Extensions using schema definition files. UserArea Extensibility: If additional content is required, each noun and component contains a UserArea component, which is intended to contain the additional content (UserArea Extensibility). The UserArea allows adding optional fields in every OAGIS component. Any new content added to a UserArea should be defined in a referenced schema file (either within OAGIS or in an imported schema file). This will ensure all BOD content is valid based on the predefined schemas. Additional fields that have been created by a user must be imported from a non-OAGIS namespace. An extended UserArea containing non-OAGIS content may, for instance, contain a declaration for the namespace, “XYZNameSpace”, along with the SchemaLocation to obtain the schema for that namespace. A downside to UserArea extensibility is there is no convenient way to restrict specific UserAreas to carry specific content. Therefore, UserArea extensibility is best used when few additions are required. Overlay Extensibility: OAGIS also makes use of schema definition files to further define additional content and improve extensibility (Overlay Extensibility). These schema definition files are used exclusively for additional content. By designing OAGIS models in this way, OAGIS has allowed users to extend the models without altering the standard set of models. This makes it possible for a user to accommodate multiple parties within the same vertical. Overlay extensibility provides a means of layering industry/vertical-specific vocabularies on the OAGIS base. These overlays can be layered on the OAGIS base or layered on other overlays to accommodate specialized vocabularies. Building on an established base enables reuse. For instance: AutoMaker123 overlay on top of AutoIndustryNorthAmerica overlay on top of OAGIS base. See Figures 2-22 and 22-23 for examples of Overlay Extensibility. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 36
    • Comparison of ISA-95 and OAGIS Figure 2-22: OAGIS Extensibility – Accommodating Multiple Parties within a Vertical Figure 2-23: Overlay Extensions to the OAGIS Overlay Extensibility allows for new layers to be defined in their own namespaces. Specialized BODs and components are defined by extending BODs from lower layers and/or by composing new BODs from a combination of existing, extended, and new components. OAGIS achieves Overlay Extensibility by relying on three schema mechanisms: 1. Incorporating XML Namespaces within the schema to eliminate the uncertainty of overlapping vocabularies 2. ComplexType derivation by extension to allow for adding content by building on existing types 3. Substitution groups to allow for replacing an element with an extended element For example, automotive industry group, AutoGroup decided to build an AutoGroup overlay extension to the OAGIS base and create new BODs. They selected a namespace, http://www.AutoGroup.org/oagis with the namespace prefix “ag.” AutoGroup needed to extend a PurchaseOrder by adding a manufacturer-suggested-retail-price (MSRP) element to the Header. They extended the OAGIS PurchaseOrder BOD to add a MSRP © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 37
    • Comparison of ISA-95 and OAGIS element of type Amount to the PurchaseOrderHeader component (complexType). This created an automotive-specific PurchaseOrderHeader component by extension: <xs:complexType name="PurchaseOrderHeader"> <xs:complexContent> <xs:extension base="oa:PurchaseOrderHeader"> <xs:sequence> <xs:element name="MSRP" type="oa:Amount" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> The extension defines only new content, all other OAGIS content is inherited from the base definition of the PurchaseOrder BOD. Next, AutoGroup defines their PurchaseOrderHeader to be in the substitution group for OAGIS’s oa:PurchaseOrderHeader: <xs:element name="PurchaseOrderHeader" type="ag:PurchaseOrderHeader" substitutionGroup="oa:PurchaseOrderHeader"/> The AutoGroup PurchaseOrderHeader can now be used as a replacement for the OAGIS PurchaseOrderHeader. Finally, AutoGroup can define its own BODs that use the newly extended type. For example, ag:ProcessPurchaseOrder, now contains an ag:MSRP element in its PurchaseOrderHeader. Any implementation of this AutoGroup overlay can now exchange the new AutoGroup ProcessPurchaseOrder BOD. If an extended element is determined to be broadly applicable (or business-canonical) by the authors, a request to have the extended element be incorporated into the OAGIS base can be submitted. If approved and incorporated, the extended element can be dropped from author’s vocabulary. If an extended vocabulary needs to be extended further by another organization, that organization can either contact the original authors of the extension for changes or create their own overlay to sit on top (see Figure 2-23). OAGIS is vertically adaptable to specific industries and enterprises. OAGIS can be nominally extended using UserArea Extensibility, a rudimentary means of plugging additional content into standard BODs. OAGIS can be more substantively extended using Overlay Extensibility, where specific, new vocabularies are built on the OAGIS base by extending existing BODs and components and/or by creating new ones. Building on an established base enables reuse. ISA-95 Extensibility ISA-95 uses a standard set of attributes that are industry and technology independent. Using all these attributes is not required, depending on the specific application. When additional content is required, properties are used to extend the standard set of attributes. OAGIS and B2MML are both XML implementations that can be extended. ISA-95 extensions need to be implemented in either OAGIS or B2MML. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 38
    • Comparison of ISA-95 and OAGIS Messaging extensibility in ISA-95 has a somewhat different objective than the OAGIS messaging extensibility. Instead of extending existing or creating new OAGIS BODs for specific vertical industries or particular enterprises, the ISA-95 approach enables a user to define additional properties for the same data object (defined in Part 2) which is contained in a “noun” (defined in Part 5). Additional ISA-95 data objects are defined for other generic manufacturing operational categories (e.g. maintenance and quality assurance testing) and for use with generic types of manufacturing processes (e.g. batch, discrete, continuous). These operational categories and types of manufacturing processes are common across multiple vertical industries and enterprises in these different industries. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 39
    • Comparison of ISA-95 and OAGIS Appendix A: White Paper Reviewers and Contributing Editors Julie Fraser, Contributing Editors, Industry Directions Inc. David M. Connelly: Contributing Editor, Open Applications Group Dave Emerson, Reviewer, Yokogawa Tim Thomasma, Reviewer, Ford Motor Company Ramana Kumar, Reviewer, Siemens Greg Gorbach, ARC Advisory Group Jim Strothman, Reviewer Appendix B: Glossary Acronyms Name Definition A2A Application-to-Application AIAG Automotive Industry Action Group APS Advanced Planning and Scheduling B2B Business-to-Business B2MML Business-to-Manufacturing Markup Language BATCHML Batch Markup Language Canonical According to standard and accepted rules, fitting the standard, and able to express full meaning simply CID Change in Design CRM Customer Relationship Management BOD Business Object Definition ECO Engineering Change Order EIMS Enterprise Integration Messaging Specification Enums Refers to “user defined enumerated types” in a programming language such as C++ ERP Enterprise Resource Planning FTP File Transfer Protocol HTML Hypertext Markup Language IEC International Engineering Consortium IMS Integration Messaging Specification ISA Standards-setting organization for manufacturing operations management and automation ISA-95 Enterprise - Control System Integration specification ISA- dS95.01-1999, ISA, July, 1999 J2EE Java 2 Platform, Enterprise Edition JMS Java Message Service MOM Manufacturing Operations Management (ISA level 3 application set) OAG Open Applications Group OAGi Open Applications Group, Inc OAGIS Open Applications Group Integration Specification OPC OLE for Process Control © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 40
    • Comparison of ISA-95 and OAGIS O&M Operations and Maintenance SCM Supply Chain Management SGML Standard Generalized Markup Language (ISO 8879) SOAP Simple Object Access Protocol SPC Statistical Process Control TBG Trade and Process Business Group UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business W3C World Wide Web Consortium WBF The Forum for Automation and Manufacturing Professionals (used to be) World Batch Forum XML eXtensible Markup Language Appendix C: 1Trademarks 1. OAGIS is a registered trademark of the Open Applications Group, Incorporated. 2. BOD is a registered trademark of the Open Applications Group, Incorporated. 3. ISA is a trademark of ISA. 4. WBF is a trademark of The Forum for Automation and Manufacturing Professionals.. 5. GE Fanuc is a trademark of General Electric Company. 6. GE is a registered trademark of General Electric Company. 7. ANSI is a trademark of American National Standards Institute Corporation. 8. IEC is a registered trademark of International Engineering Consortium. 9. ISO is a registered trademark of International Organization for Standardization. 10. American Software is a registered trademark of American Software, Inc. 11. CODA Financials is a registered trademark of CODA Financials, Inc. 12. Dun&Bradstreet is a registered trademark of Dun & Bradstreet Inc. 13. Oracle is a registered trademark of Oracle International Corporation. 14. PeopleSoft is a registered trademark of Oracle International Corporation. 15. SAP is a trademark of SAP AG in Germany and in other countries. 16. Software 2000 is a registered trademark of Software 2000, Inc. 17. IBM is a registered trademark of International Business Machines Corporation. 18. Ford is a registered trademark of Ford Motor Company. 19. Boeing is a registered trademark of Boeing Company. W3C is a registered trademark of Massachusetts Institute of Technology. 20. OPC is a trademark of OPC Foundation. 21. Sun is a registered trademark of Sun Microsystems, Inc. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 41
    • Comparison of ISA-95 and OAGIS 22. iPlanet is a registered trademark of Sun Microsystems, Inc. 23. VisualBasic is a registered trademark of Microsoft Corporation. 24. Delphi is a registered trademark of Inprise. 25. Rockwell Automation is a registered trademark of Rockwell International Corporation. 26. Cisco Systems is a trademark of Cisco Systems, Inc. 27. General Motors is a registered trademark of General Motors Corporation. Appendix D: References 1. OAGi White Paper – Plug and Play Business Software Integration, The Compelling Value of the Open Applications Group, David Connelly, CEO, Open Applications Group, Inc, 1995. 2. The Open Applications Group Integration Specification, Michael Rowell, Open Applications Group, Inc, June, 2003. 3. XML Excellence at Ford Motor Company, Tim Thomasma, XML Journal, Volume 3, Issue 9, September, 2002. 4. OAGIS 8: Practical integration meets XML Schema, Mark Feblowitz, XML Journal, Volume 3, Issue 9, September, 2002. 5. XML in the Auto Industry: Summer 2002, Pat Snack and Sig Handleman, XML Journal, Volume 3, Issue 9, September, 2002. 6. ANSI/ISA-88.01, Batch Control Part 1: Models and Terminology, ISA, 2000. 7. ANSI/ISA-88.00.02, Batch control - Part 2: Data Structures and Guidelines for Languages, ISA 2001. 8. ANSI/ISA-95.00.01, Enterprise-Control System Integration Part 1: Models and Terminology, ISA 2000. 9. ANSI/ISA 95.00.02, Enterprise-Control System Integration Part 2: Object Model Attributes, ISA 2000. 10. ISA-88, Batch Control- Part 3: General and Site Recipe Models and Representation, ISA 2002. 11. ANSI/ISA-95.00.03, Enterprise-Control System Integration Part 3: Models of Manufacturing Operations Management, 2005. 12. ISA-88, Batch Control - Part 4: Batch Production Records, ISA 2006. 13. ISA-95 Part 5 (Draft 11), Business-to-Manufacturing (B2M) Transactions, ISA 2006. © Copyright IBM Corp., Rockwell Automation and GE-Fanuc 2006. All rights reserved 42