How To Create An Enterprise Class Model Driven Integration

Transcription

1 Creating an Enterprise Class Scalable Model Driven Infrastructure The use case for using IBM, OSIsoft, and SISCO technologies Version: 1.1 Date: May 28, 2009 Systems Integration Specialist Company, Inc ½ Mile Road Sterling Heights, Michigan 48314

2 Creating an Enterprise Class Scalable Model Driven Infrastructure Page 2 Introduction In order to understand Enterprise Model Driven Integration, it is important to first understand the business use case for the integration. In order to discuss integration from a general perspective, this paper will utilize the ISA 95 standard. This paper leaves it to the reader to correlate the ISA 95 information/business drivers for their purposes. Figure 1: ISA 95 Functional Levels of Integration 1 Figure 1 depicts the four levels of integration/information exchange as defined by ISA 95. The figure shows distinct integration/information exchange boundaries (e.g. between levels 3-4 and levels 2-3), reality has shown that the boundaries are not as well defined and that functions are not necessarily as well segmented as are shown. An implementation view could show something similar to Figure 2. ERP MES Process Coordination Information Exchange Process Business Process Choreography User Interaction 1 Courtesy of Keith Unger, Stone Technologies.

3 Creating an Enterprise Class Scalable Model Driven Infrastructure Page 3 Figure 2: Possible Implementation Architecture Each implementation layer, shown in Figure 2, could have its own set of tooling and user interfaces. Additionally, a single layer might make use of different equipment from one or more vendors. The choice for particular equipment is driven by business requirements. The selected vendors would typically provide tooling and user interfaces for their equipment to maximize the user experience with the equipment. In so doing, expertise and advocacy for particular tooling is developed within the business organization which has the end effect of creating silos of expertise. Consider the programming of two (2) different PLCs. Both PLC s monitor the production level of particular business work centers. One PLC has been programmed to provide the information in register The other exposes production level in register I:177/17. The users that programs each PLC has the documentation that details which register represents the production level of the cell. However, it would be difficult for a non-plc expert to know which register, or the different notations/tooling, to acquire the production levels of each cell. Similar examples of data naming issues can typically be found between different product offerings, even potentially from the same vendor. Historians Tag Name Address Space Distributed Control Systems Register Address Space Low Level Automation Controllers and I/O Figure 3: Normal Implementation Architecture to create contextual Tags Use of Tags In order to provide some context for the automation information, this information is typically placed/used by higher level systems that provide the capability to alias automation information into human recognizable names (e.g. Tags). Figure 3 depicts typical integration/process integration where the low level automation information is exposed through either Distributed Control Systems (DCSs) or through historians. There are multiple DCS and historian vendors that could be utilized within each integration level in a corporate enterprise environment. Each vendor, as with the automation integration level, has special constraints on Tag naming. Therefore, the general user/application is still required to understand the special constraints of the system that needs to be accessed for a particular application/display.

4 Creating an Enterprise Class Scalable Model Driven Infrastructure Page 4 However, the single vendor selection strategy is not sufficient. Additionally, a corporate policy for Tag naming needs to be developed and enforced. However, history has shown that even where there are strong corporate policies, Tag name consistency does not occur in an enterprise due to several different reasons: Configuration errors: In order to comply with corporate naming policies, people must configure the Tag names that correlate to particular automation information. This is typically a manual process and is prone to errors (e.g. Level and Lvel). Detection of such errors requires a large amount of naming/data validation. Constraints on the Tag namespace: Most Tag namespaces do not allow for duplication of Tag names. Therefore, if the higher level integration levels need to expose more than one Level Tag, the names are inherently forced to be unique. This issue can be solved by adding an extension to the Tag name in order to provide uniqueness. Most typical corporate policies dictate that the name of the system, work center, etc. be pre-pended to the tag name. As an example, the Level for SeparatorTrain1 and SeparatorTrain2 needs to be provided. The corporate mandated naming convention might specify the Tag names to be SeparatorTrain1_Level and SeparatorTrain2_Level. Most corporate naming conventions must take into account the business hierarchy. This policy could extend the length of the Tag name to include: <oil field name>_<platform name>_<production unit name>_<measurement name> Names of entities change: One thing that has been proven is that over time names of platforms/production units may be changed. The end effect, of such changes, is that as platforms/production units names are changed, maintenance of the Tag names, and the applications that utilize them, may become an issue. Hierarchical Tag naming creates issues for other business views: The process business view is the typical standard used to name Tags. However, there are other business related views (e.g. AssetUtilization, Condition Based, others ) that would be better facilitated by the use of another naming hierarchy/view of the information. In general, this is an issue with technologies that only support hierarchical data organization. Mergers and acquisitions: Experience has shown that most corporate Tag naming policies do not provide naming conventions that include naming associated with the corporation or underlying business units. The lack of this information in the name can create integration issues when corporations merge. Use of Models In 1999, the Electric Power Research institute had an initiative to develop a standardized model and a set of model access services. The intent of the initiative was to address the previously mentioned issues in

5 Creating an Enterprise Class Scalable Model Driven Infrastructure Page 5 addition to many others. SISCO has been involved in developing integration products and solutions utilizing semantic models and Model Driven strategies. Semantic Models A semantic model is typically considered as: a basic set of ontology elements classes, relations, functions, instances, intended to serve as the conceptual defining vocabulary that will permit specification of the meanings of any domain term or concept. It serves a function analogous to the controlled defining vocabularies used in some traditional dictionaries to define words. 2 As an example, ISA 95 and ISA 88, define a semantic model that can be utilized in discrete and batch oriented process 3 that go well beyond defining a hierarchy of measurement/process data access. Specified by ISA-88 Identified Specified by ISA-88 ISA-95 Enterprise Must Contain 1 or More Site May Contain 1 or more Area May Contain 1 or more Process Cell Must Contain 1 or More Unit Manufacturing Line Must Contain 1 or More Work Cell Unit Must Contain 1 or More Unit Storage Zone Must Contain 1 or More Storage Unit May Contain May Contain Equipment Module May Contain Discrete Continuous May Contain Control Module Batch Figure 4: Simplified representation of ISA 95 and ISA 88 Physical Model 4 Each block, shown is Figure 4, represents object definitions (e.g. expressible as UML classes) that contain specific attribute definitions and types for the specified attribute. Although, Figure 4 appears to be able to be expressed as a hierarchy, the diagram represents only one potential view of the process oriented business functions. A more accurate representation of the interactions/views required is shown in Figure 5. 2 Mitre Corporation 3 There are other well recognized semantic models such as MIMOSA, CIM, ISO 15926, IEC 61850, etc.. 4 Courtesy of Keith Unger, Stone Technologies.

6 Creating an Enterprise Class Scalable Model Driven Infrastructure Page 6 How Product Lifecycle ISA 95 Definitions Enterprise Planning and Logistics Information What Resource Planning ISA 95 Capability When Schedule / Plan ISA 95 Request Delivery Fulfillment ISA 95 Response Definition Management Resource Management Detailed Scheduling Tracking Dispatching Analysis Execution Management Equipment Specific Definitions Commands Responses Data Collection Receiving Batch / Continuous and Discrete Work Centers Shipping Figure 5: ISA 95 Manufacturing Activities 5 Equipment Specific Data J. Keith Unger The figure 5 shows not only the manufacturing interactions, but the views of information/context that need to be supported. In order to create the multiple views (e.g.,,, and ), mesh oriented model repositories/namespaces need to be utilized instead of hierarchical namespaces. In order to address the Tag oriented integration issues, enforcement of the class/attribute definitions is required. Additionally, the possible relationships between instances needs to be appropriately specified (e.g. UML associations). It is through the specification of the relationships that multiple business views of the information can be created. Implementations of Data Warehouses/Model Repositories that expose such instance relationships would be considered Model Aware. Model Driven Although there are several technologies that can be utilized to create Model Aware repositories, there is a difference between repositories that are Model Aware and enterprise integration strategies that are Model Driven. Model Driven integration strategies need to encompass the functionality of being Model Aware and the additional functionality of: Support for a work flow that allows for the maintenance of the model within the model repository(s). The work flow should be able to be integrated into choreographed business processes. This is required so that model updates can be validated and model changes do not occur at an inopportune time. Although, this workflow can be achieved manually, it is recognized that electronic 5 Courtesy of Keith Unger, Stone Technologies.

7 Creating an Enterprise Class Scalable Model Driven Infrastructure Page 7 coordination, which integrates with other business process, offers higher business value. This includes the dynamic modification of the model due to process changes and business transactions (e.g. new Work Orders, Batch commands, etc..). Since 1999, SISCO has developed products that implement those strategies. Over time, SISCO has evolved its integration strategy to be applicable to other industries besides the electrical utility industry. The resulting product family name is the SISCO Utility Integration Bus (UIB). The initial UIB product provided a Model Driven integration infrastructure that utilized a model repository to create Model Aware/Driven adapters that exchanged information over middleware. SISCO offers a select set of adapters for the infrastructure: OPC Client Adapters: Allows applications, which are OPC clients, to access information, in the context of the model, without requiring the creation of a Data Warehouse or knowledge of the authoritative source of the information. OPC Server Adapters: Allows applications, which are OPC Servers, to have their information mapped into the model and be exposed to the infrastructure as an authoritative source. Adapter for OSIsoft PI: Allows the enterprise model to be imported/maintained within the PI Module DataBase or PI AF 6. This adapter allows for PI client applications (e.g. ProcessBook, RtWebParts, and DataLink) to be used in a Model Driven fashion. One of the desires, for the infrastructure, was to have the capability of electronic business choreography. This ability is now provided within the IBM Integration and Information Framework (IIF) solution. Additionally, IIF natively allows for electronic business transactions (e.g. EDI, S95, etc...) to be translated and responded to in terms of the model. Through the appropriate selection of the appropriate products, and architecture, users can create flexible integration deployments. Architecture Due to the flexibility of the various product offerings, users will need to select the appropriate set of products based upon corporate commitments to specific technologies, client application environment, and desired business functions. From a functional perspective, the suite of available products needs to be functionally classified. For this purpose, it is desirable to use the following diagram: 6 OSIsoft has a stated strategy of transitioning away from the MDB to AF. SISCO is following that strategy and is not currently updating the capabilities of the MDB version of the PI Adapter.

8 Creating an Enterprise Class Scalable Model Driven Infrastructure Page 8 Figure 6: Simplified Enterprise Integration Functions

9 Creating an Enterprise Class Scalable Model Driven Infrastructure Page 9 There are several different functional layers depicted in Figure 6: Data Layer: Actually obtains information from the real-time process automation equipment/sensors. Information Layer: Applies the semantics of the model to change data into contextual information. One of this layer s capabilities is to access automation/process information via SOA. Business Process Layer: Allows configuration and implementation of workflow coordination on an Enterprise level. It also provides a transactional capability (e.g. create a new purchase order, execute a general batch, etc) from other SOA system. It is typical for each layer to have one or more visualization components that are used to expose the information from the layer. Therefore, the strategy does not mandate a single visualization component s use and must be flexible to accommodate multiple tools. However, it is desirable to be able to combine a subset of the visualization tools, at least one from the Information and Business layer, into a single method of access to the tools. This would typically be accomplished through exposing the visual information through a single web portal technology (e.g. Websphere, SAP, or Microsoft) at the discretion/selection of the customer. Figure 7: Components of the combined SISCO, IBM, and OSIsoft infrastructure Figure 7 shows the components/products that are used to create a model-driven infrastructure through combining the IBM s Information Integration Framework (IIF) solution with SISCO and OSIsoft products.

10 Creating an Enterprise Class Scalable Model Driven Infrastructure Page 10 Model Driven Infrastructure Figure 8: Functional use of infrastructure components IIF is an IBM software solution that is being leveraged for solutions in the domains of: Chemical and Petroleum; Energy and Utilities; and other business application domains. The solution is based upon IBM products which, in the past, have provided: Complex Business Process Orchestration and Mediation: This functionality is provided by the IBM s Webshpere Business Process Server. This product allows the definition of complex business process interactions and workflow through the use of graphical configuration and Business Process Execution Language (BPEL) technology. Mediation and transformation of SOA messages: This functionality is provided within the Websphere Application Server (WAS) product. Middleware message transport and security: Provided through the Websphere Enterprise Service Bus. IIF adds model awareness to the components through a set of standards based Model related services. These services allow: Real-time information to be consumed by the applications so that the business workflow can adapt based upon the current state of the actual processes within the enterprise. As an example, consider the reception of an SOA transaction that is used to dispatch a production batch to a specific production unit. However, that production unit is offline or has not completed its current batch. The real-time information of the status of the production unit (e.g. that it is not available) allows, through BPEL, to re-dispatch the batch to an alternate production unit(s) that are available and are capable of producing the batch.

11 Creating an Enterprise Class Scalable Model Driven Infrastructure Page 11 The applications to query the virtualized model so that relationships/capabilities of equipment, production units, measurements, etc. can be determined. The previous batch example implies that the re-dispatching is based upon the knowledge of which other production units are capable of producing a specific type of batch. The ability to query the model for this information allows BPEL to dynamically determine which units meet the criteria as opposed to being programmed (e.g. a priori) with the information. This allows the designers of the production cells/units to change the model, and thereby allow adaption in the workflow coordination, without requiring changes to the BPEL. It is the ability to change the model and impact the coordination that is at the root of enabling the entire orchestration to be Model Driven. Historical information to be consumed by the applications in order to determine/adapt business processes based upon past performance. Applications to be coordinated and production and business process related metrics/events to be produced or consumed as part of the overall coordination process. As part of facilitating the application functionality, IIF also includes SISCO Utility Integration Bus (UIB) components. The SISCO UIB PI Adapter is used to populate and manage (e.g. update) OSIsoft s AF repository with a subset of the overall virtual enterprise model. The PI Adapter also allows the historical and real-time information within the OSIsoft Server(s) to be exposed in the context of the enterprise model to the ESB. The product also allows the IIF business oriented applications to store the business process generated metrics/events to be stored within the OSIsoft environment. Figure 7 shows the most typical OSIsoft products that would be utilized in the architecture. These products provide the capability of: Generation of process/production related Key Performance Indicators as well as a mechanism to generate events that can be consumed as part of the business choreography within the IIF solution and other components in the architecture. Publication of process information to the infrastructure (e.g. through the SISCO PI Adapter) in realtime. Provides a repository for historical production process and business process information. Provides a repository for a subset of the enterprise model so that OSIsoft tooling can be used to visualize/report the information within the context of the enterprise model.

12 Creating an Enterprise Class Scalable Model Driven Infrastructure Page 12 Summary Through the deployment of world-class products from IBM, OSIsoft, and SISCO; a robust Model Driven infrastructure can be created that addresses the functional requirements of Enterprise integration. Figure 9: Infrastructure components vs. enterprise integration layers The solution also allows business process, production and Manufacturing Execution System (MES), and process level coordination to occur. Figure 10: Infrastructure components vs. scope of applicability and ISA levels

13 Creating an Enterprise Class Scalable Model Driven Infrastructure Page 13 For more details, please contact Systems Integration Specialists Company. Acknowledgements SISCO gratefully acknowledges the contributions of Troy Carbaugh, Lorenzo Childress, Herbert Falk, and Ron Montgomery for their input and assistance in the creation of this paper.