MIMOSA Open System Architecture for Enterprise Application Integration

MIMOSA Open System Architecture for Enterprise Application Integration (OSA-EAI) Primer September 2008 Ken Bever MIMOSA CTO/Technical Director kbever@mimosa. org Principal Consultant, Assetricity LLC AMRDEC Software Engineering Directorate ken. bever@us. army. mil 513 -276 -4105 September 2008 1

Goals of Training ►Fundamental understanding of the breadth and depth of the MIMOSA specifications ►Provide sample database and tools for further exploration/study ►Target audience: – Technical Program Managers – Software/System Integrators – Software Developers September 2008 2

Oil&Gas Industry Asset Management Data Integration Challenges ►Extremely complex platforms with many components ►Overwhelming data volumes ►Multiple data “languages” – Multiple formats of data from a variety of systems – Vendors promote their proprietary data standard as the optimal for a specific application September 2008 3

Oil&Gas Industry Asset Management Data Integration Challenges ►Extremely complex, constantly moving assets of various types ►Overwhelming data volumes ►Multiple data “languages” – Multiple formats of data from a variety of systems – Vendors promote their proprietary data standard as the optimal for a specific application September 2008 4

Oil&Gas Industry Asset Management Data Integration Challenges ►Extremely complex, constantly moving assets of various types ►Overwhelming data volumes ►Multiple data “languages” – Multiple formats of data from a variety of systems – Vendors promote their proprietary data standard as the optimal for a specific application September 2008 5

Oil&Gas Industry Asset Management Data Integration Challenges What Data About Current and Future Plant Capability Does My ERP System Need? (KPIs, Order Management, Supply Chain, Financial, Materiel, Logistics, HR) How Can I Access My Engineering Design Information and RCM Study Data? How Can I Feed Asset Capability Data Into My Production Optimization, Planning & Scheduling Systems? How Can I Access My Physical Plant Configuration and Installed Equipment Registry Components (Past & Present)? How Can I Change My Maintenance Systems into “Condition-based” and Access Necessary Maintenance Data – Past, Present, and Future? (people, parts, plans, tools, and time) How Can My Control Systems, Plant Data Historians & Plant Asset Health/Safety/Environmental Systems Provide Timely and Relevant Data and Events to all Other Enterprise Systems? September 2008 6

Oil&Gas Industry Asset Management Data Integration Challenges Enterprise HR, Financial, Materiel, Logistics, & Mission Capability Data EPC & OEM Engineering Product Design Data & Reliability Study Data Production Optimization, Planning & Scheduling Serialized Asset Registry & Lifecycle Configuratio n Management Data Maintenance System Data P 4 T 2 (problem, plan, people, parts, tools, and time] Control Systems, Plant Data Historians & Plant Asset Health/Safety/Environmental Systems Data September 2008 7

How Best to Integrate the 100+ Systems? Enterprise HR, Financial, Materiel, Logistics, & Mission Capability Data EPC & OEM Engineering Product Design Data & Reliability Study Data Production Optimization, Planning & Scheduling Serialized Asset Registry & Lifecycle Configuratio n Management Data Maintenance System Data P 4 T 2 (problem, plan, people, parts, tools, and time] Control Systems, Plant Data Historians & Plant Asset Health/Safety/Environmental Systems Data September 2008 8

How Best to Integrate the 100+ Systems? Enterprise HR, Financial, Materiel, Logistics, & Mission Capability Data EPC & OEM Engineering Product Design Data & Reliability Study Data Production Optimization, Planning & Scheduling Serialized Asset Serialized Registry & Asset Registry Proprietary Middleware &Lifecycle Configuratio Data Bridge Configuration n Management Data Maintenance System Data P 4 T 2 (problem, plan, people, parts, tools, and time] Control Systems, Plant Data Historians & Plant Asset Health/Safety/Environmental Systems Data September 2008 9

Teach Them To Speak the Open. O&M Languages! Enterprise HR, Financial, Materiel, Logistics, & Mission Capability Data ISO 15926 EPC & OEM Engineering Product Design Data & Reliability Study Data Production Optimization, Planning & Scheduling Serialized Asset Registry & Lifecycle Configuratio n Management Data Maintenance System Data P 4 T 2 (problem, plan, people, parts, tools, and time] Control Systems, Plant Data Historians & Plant Asset Health/Safety/Environmental Systems Data September 2008 10

MIMOSA OSA-EAI Design OSA-EAI Information Architecture WORK FLOW PROCESSES PEOPLE-DRIVEN APPLICATIONS APPLICATION DATA & EVENTS September 2008 COMPUTER-DRIVEN APPLICATIONS AUTOMATION DATA & EVENTS 11

MIMOSA OSA-EAI Design OSA-EAI Information Architecture WORK FLOW PROCESSES PEOPLE-DRIVEN APPLICATIONS APPLICATION DATA & EVENTS September 2008 COMPUTER-DRIVEN APPLICATIONS AUTOMATION DATA & EVENTS 12

MIMOSA OSA-EAI Design OSA-EAI Information Architecture WORK FLOW PROCESSES PEOPLE-DRIVEN APPLICATIONS APPLICATION DATA & EVENTS September 2008 COMPUTER-DRIVEN APPLICATIONS AUTOMATION DATA & EVENTS 13

MIMOSA OSA-EAI Design WORK FLOW PROCESSES PEOPLE-DRIVEN APPLICATIONS COMPUTER-DRIVEN APPLICATIONS MIMOSA Common Relational Information Schema (CRIS) APPLICATION DATA & EVENTS September 2008 AUTOMATION DATA & EVENTS 14

MIMOSA OSA-EAI Design WORK FLOW PROCESSES PEOPLE-DRIVEN APPLICATIONS COMPUTER-DRIVEN APPLICATIONS MIMOSA Data Access Web Services (Tech-XML / Tech-CDE) & MIMOSA Data Access Messaging (Tech-Message) MIMOSA Common Relational Information Schema (CRIS) APPLICATION DATA & EVENTS September 2008 AUTOMATION DATA & EVENTS 15

MIMOSA OSA-EAI Design WORK FLOW PROCESSES PEOPLE-DRIVEN APPLICATIONS COMPUTER-DRIVEN APPLICATIONS MIMOSA Data Access Web Services (Tech-XML / Tech-CDE) & MIMOSA Data Access Messaging (Tech-Message) MIMOSA Common Relational Information Schema (CRIS) APPLICATION DATA & EVENTS September 2008 AUTOMATION DATA & EVENTS 16

Historian System Integration Platform Data Process-modeling & optimization Reconciliation System Data Engineering CAD/CAE Systems Document Management Data Lab Information Management Process Modeling Systems. Data Planning and Dispatch Systems Data Environmental Monitoring System September 2008 Pre-packaged Adaptors/ Connectors Message Transport Maintenance System Workflow Encryption, Audit, Security Adapter Development Kit Integration Administration Message Routing & Brokering Data Mapping & Transformation Message Transportation Basic Admin Advanced Suncor View -- A Coordinated Approach to Full Integration within the Enterprise Data Index Analysis Tools Spreadsheets “Portals” 17

What is an Open. O&M Information Model? ► Representation of the information objects required for the business based on defined set of Open. O&M standards ► Contains the things of importance in an organization and how they relate to one another ► Provides a basis for physical database design but does not mandate a particular data storage format. The physical design of a database involves deep use of particular database management technology. Information Model September 2008 Physical Data Model 18

Why Use an Open. O&M Information Model? ► Helps common understanding of business requirements ► Provides foundation for designing databases and bulk binary datastores, and data warehouses ► Facilitates data re-use and sharing ► Decreases development and maintenance time and cost ► Focuses on information requirements independent of technology and changing processes ► Decreases system development time and cost ► Becomes a template for the enterprise ► Facilitates data re-use and sharing ► Faster ROI ► Gathers metadata ► Fosters seamless communication between applications ► Focuses communication for data analysis and project team members ► Establishes a consistent naming scheme September 2008 19

Why Use an Open. O&M Model? Most Current Applications Are Designed to Work Closely-Coupled to a Supplier. Specific Proprietary Database Application A Proprietary Data Model Application A Transactional Data September 2008 20

Why Use an Open. O&M Model? Software Engineering Best Practice Dictates A Separation of the Application from the Required Data it Needs Application A Proprietary Data Model Application A Transactional Data September 2008 21

Why Use an Open. O&M Model? World Class Enterprises Are Now Designing an Enterprise-owned Information Model Abstraction Layer Which Hides Proprietary Data Models Application A Open. O&M Model & Bus Open. O&M Information Model & Open. O&M Information Service Bus Application A Transactional Data September 2008 Proprietary Data Model 22

Why Use an Open. O&M Model? This Allows Many New Applications to be Built With Just Knowledge of the Enterprise Information Model Application A Application B Application C Open. O&M Information Model & Open. O&M Information Service Bus Application A Transactional Data September 2008 Open. O&M Model & Bus Proprietary Data Model 23

Open. O&M Information Strategy Application Supplier A Has the Option to Keep Proprietary Data Model or Evolve to Natively Use Open. O&M Information Model For Some/All Data Application A Open. O&M Information Model Application B Open. O&M Information Model & Open. O&M Information Service Bus Open. O&M Model & Bus Proprietary Data Model Application A Transactional Data September 2008 Application C Application A Transactional Data 24

MIMOSA Tech-Message Support for “Fire-and-Forget” Pub/Sub Pattern Publisher Application Subscriber Applications Tech-Message On-Ramp/Off-Ramp Services Proprietary ESB / MOM / SOA Engines nts Tech-Message Header with Tech-CDE, Tech-Doc, or Tech-XML Body “System of record” events Message Routing Store-and-Forward Caching Exception Management MIMOSA OSA-EAI Services Publishes “system of record” change events MIMOSA OSA-EAI Services ESB / MOM / SOA Core Engine c f re mo ste “Sy B 2 B Gateway Receives events “System of record” events “Sy ste m Provisioning Framework eve ” d or of r eco rd” eve nts Topic Registry Management System Service Management Security September 2008 25

MIMOSA Tech-Message Support for “Fire-and-Forget” Pub/Sub Example Application A P P Application D P Application E P Application F P Application B P Secure Message Bus P Application C September 2008 P P Published Message from Application A which Applications D & E have Subscribed To Receive P Published Message from Application F which Applications B & C have Subscribed To Receive 26

MIMOSA Tech-Message Support for “Sync” Pub/Sub Pattern Publisher Application Subscriber Applications Tech-Message On-Ramp/Off-Ramp Services Proprietary ESB / MOM / SOA Engines nts “System of record” events Delivered to Subscriber A Message Routing Store-and-Forward Caching Exception Management c f re mo e st “Sy d to ere eliv Provisioning Framework B 2 B Gateway A ber scri Sub D “System of record” events Delivered to Subscriber B “Sy ste m Delivered to Subscriber B Delivered to Subscriber C MIMOSA OSA-EAI Services Tech-Message Header with Tech-CDE or Tech-XML Body MIMOSA OSA-EAI Services ESB / MOM / SOA Core Engine eve ” d or De live of r red eco rd” to S ubs Topic Registry Management eve crib nts er C System Service Management Security September 2008 27

MIMOSA Tech-Message Support for Targeted “Push” Pattern Sender of Push Application Tech-Message On-Ramp/Off-Ramp Services Proprietary ESB / MOM / SOA Engines Receiver of Push Application Pushed Data Results of Push Requests MIMOSA CRISformatted Information with a-priori Knowledge of Name of Target Receiver Application Message Routing Store-and-Forward Caching Exception Management Provisioning Framework B 2 B Gateway MIMOSA OSA-EAI Services Tech-Message Header with Tech-CDE or Tech-XML Body MIMOSA OSA-EAI Services ESB / MOM / SOA Core Engine Pushed Data Results of Push Responds to Push in an Appropriate Way System Service Maagement Security September 2008 28

MIMOSA Tech-Message Support for Targeted “Pull” Pattern Query Client Application Tech-Message On-Ramp/Off-Ramp Services Query Server Application Proprietary ESB / MOM / SOA Engines Query Results Requests MIMOSA CRISformatted Information with a-priori Knowledge of Name of Target Server Application Message Routing Store-and-Forward Caching Exception Management Provisioning Framework B 2 B Gateway MIMOSA OSA-EAI Services Query MIMOSA OSA-EAI Services ESB / MOM / SOA Core Engine Query Results Responds to Queries System Service Maagement Security September 2008 29

MIMOSA Tech-Message Support for Untargeted “Scatter/Gather” Pattern Query Client Application Query Server Applications Tech-Message On-Ramp/Off-Ramp Services Proprietary ESB / MOM / SOA Engines Query Results Message Routing Store-and-Forward Caching Exception Management MIMOSA OSA-EAI Services Tech-Message Header with Tech-CDE or Tech-XML Body MIMOSA OSA-EAI Services ESB / MOM / SOA Core Engine ery Qu Query Results “Sy ste m Requests MIMOSA CRISformatted Information without a-priori Knowledge of Server Applications Provisioning Framework B 2 B Gateway lts esu ry R Que of r eco Qu ery rd” Re sul ts eve nts System Service Maagement Security September 2008 30

MIMOSA Tech-Message Services for an Open. O&M Information Service Bus Tech-Message Bus On. Ramp & Off. Ramp Vendor App Computer A September 2008 Computer B 31

MIMOSA’s Two Open Standards At Platform Diagnostics Maintenance Logistics Portable Diagnostic Tools EAM, CMMS Tightly Coupled Systems September 2008 INFORMATION SYSTEMS EMBEDDED SYSTEMS MIMOSA OSA-EAI Information Architecture Standard MIMOSA OSA-CBM Processing Architecture Standard Loosely Coupled Systems Copyright 2007 MIMOSA 32

ISO 13374 Standard • Published standard for open software specifications which will allow machine condition monitoring data and information to be processed, communicated and displayed by various software packages without platform-specific, vendor-specific, or hardwarespecific protocols • ISO 13374 Parts 1 and 2 provide an informative Annexes which provides a reference to the open, vendor-neutral, XML-based consensus standards which are compliant with the architecture as described • MIMOSA’s OSA-EAI and OSA-CBM Specifications are currently the only ones listed as compliant in this Annex September 2008 33

OSA-EAI Based Upon 5 -Layer ISO 13374 -2 Open Information Architecture Requirements Data Document Definitions Reference Data Library Implementation Data Model Conceptual Information Model Semantic Definitions September 2008 34

OSA-EAI Based Upon 5 -Layer ISO 13374 -2 Open Information Architecture Requirements OSA-EAI Information Architecture Tech-Doc & Tech-CDE XML Document Schema CRIS Reference Data Library Common Relational Information Schema (CRIS) Common Conceptual Object Model (CCOM) Terminology Dictionary September 2008 35

MIMOSA OSA-EAI Specification ► ISO 13374 compliant information architecture ► Built upon a Common Conceptual Object Model (CCOM) ► Converted into Relational Implementation Model called the Common Relational Information Model (CRIS) that can be implemented ► Specifications packaged for interoperability of: – Registry information for model nameplate information / asset registries / maint. breakdowns / resources (parts/tools/consumables) – Reliability information – Condition event data – Condition measurement data • • • Scalar data Dynamic data (vibration / sound) Test data Sample data Binary data – Diagnostic / prognostic / health assessment information – Work management information ► Designed to transfer archived data which is normally stored in a database ► No middleware required September 2008 36

MIMOSA OSA-EAI Interfaces ► MIMOSA Open System Architecture for Enterprise Application Integration (OSA-EAI) Core Technology – Built upon a Common Conceptual Object Model (CCOM) – Converted into an Relational Implementation Model called the Common Relational Information Model (CRIS) – Specifications packaged for Interoperability of: • Model Nameplate Information / Asset Registries / Maint. Breakdowns • Work Management Systems • Diagnostic / Health Assessment Systems • Process Data Historian Systems • Dynamic Vibration / Sound Data Condition Monitoring Systems • Lab Information Management Systems • Test and Measurement Systems • Binary / Thermography Condition Monitoring Systems • Reliability Database Systems – Designed to Transfer Archived Data Which Is Normally Stored in a Database – No Middleware Required September 2008 Copyright 2007 MIMOSA 37

MIMOSA OSA-EAI Interfaces ► MIMOSA OSA-EAI Interfaces – Tech-Doc Interfaces defines CRIS XML documents of any size to use over any transport protocol – Tech-CDE (Compound Document Exchange) defines aggregate CRIS database queries and inserts/updates with Client/Server XML interfaces – Tech-XML Interfaces define discrete CRIS Client/Server XML transactions – Tech-File Export specification details the requirements for an application which will be exporting its data in Tech-Doc form – Tech-CDE-Services specification details the requirements for client/server Web applications which are running. Tech-CDE transactions over SOAP transport protocol – Tech-XML-Web specification details the requirements for client/server Web applications which are running Tech-XML transactions over HTTP transport protocol – Tech-XML-Services specification details the requirements for client/server Web applications which are running Tech-XML transactions over SOAP transport protocol September 2008 Copyright 2007 MIMOSA 38

MIMOSA Open Systems Architecture for Enterprise Application Integration (OSA-EAI) Open Reliability Management Open Maintenance Management Open Object Registry Management Open Condition Management September 2008 Copyright 2007 MIMOSA 39

OSA-EAI Open Object Registry Management September 2008 Meta-Data, Registry, & Current/Historical Configuration for: • Enterprises • Sites • Functional Segments • Segment Hierarchies & Named Relationships (Networks) • Databases & Mapping Info • OEM Model & Nameplate Specs • Physical Assets with Segment Installation • Agents • Resources ( Parts/Consummables/Tools/Labour) 40

MIMOSA OSA-EAI Specification ► ISO 13374 compliant information architecture ► Built upon a Common Conceptual Object Model (CCOM) ► Converted into Relational Implementation Model called the Common Relational Information Model (CRIS) that can be implemented ► Specifications packaged for interoperability of: – Registry information for model nameplate information / asset registries / maint. breakdowns / resources (parts/tools/consumables) – Reliability information – Condition event data – Condition measurement data • • • Scalar data Dynamic data (vibration / sound) Test data Sample data Binary data – Diagnostic / prognostic / health assessment information – Work management information ► Designed to transfer archived data which is normally stored in a database ► No middleware required September 2008 41

Understanding UML Class Diagrams Class ► The core element of the class diagram is the class. In an object oriented system, classes are used to represent entities within the system; entities that often relate to real world objects. ► The Contact class to the right is an example of a simple class that stores location information. ► Classes are divided into three sections: – Top: The name, package and stereotype are shown in the upper section of the class. – Center: The center section contains the attributes of – Bottom: In the lower section are the operations that can be performed on the class. September 2008 42

Understanding UML Class Diagrams Generalization ► The generalization link is used between two classes to show that a class incorporates all of the attributes and operations of another, but adds to them in some way. ► In the diagram to the right, we again see our Contact class, only now with two child classes. We can say that Client and Company inherit, generalize or extend Contact. In each of Client and Company all of the attributes in Contact (address, city, etc. ) exist, but with more information added. In the above situation Contact is said to be the superclass of Client and Company. September 2008 43

Understanding UML Class Diagrams Associations ► Classes can also contain references to each other. The Company class below has two attributes that reference the Client class. ► The first association (the top one) represents the old contact. Person attribute. There is one contact person in a single Company. The multiplicity of the association is one to one meaning that for every Company there is one and only one contact. Person and for each contact. Person there is one Company. In the bottom association there are zero or many employees for each company. Multiplicities can be anything you specify. Some examples: 0 1 1. . * * or 0. . * = zero = one to many = zero to many ► The arrows at the end of the associations represent their navigability. In the above examples, the Company references Clients, but the Client class does not have any knowledge of the Company. You can set the navigability on either, neither or both ends of your associations. If there is no navigability shown the navigability is unspecified. September 2008 44

Understanding UML Class Diagrams Composition ► The example below shows an aggregation association and a composition association. ► The composition association is represented by the solid diamond. It is said that Product. Group is composed of Products. This means that if a Product. Group is destroyed, the Products within the group are destroyed as well. ► The aggregation association is represented by the hollow diamond. Purchase. Order is an aggregate of Products. If a Purchase. Order is destroyed, the Products still exist. ► If you have trouble remembering the difference between composition and aggregation, just think of the first 4 letters of the alphabet A through D. Aggregation means you can keep Building with the child classes if the parent class is destroyed. Composition means you must Destroy all the child classes if the parent class is destroyed. September 2008 45

OSA-EAI Open Object Registry Management September 2008 Meta-Data, Registry, & Current/Historical Configuration for: • Enterprises • Sites • Functional Segments • Segment Hierarchies & Named Relationships (Networks) • Databases & Mapping Info • OEM Model & Nameplate Specs • Physical Assets with Segment Installation • Agents • Resources ( Parts/Consummables/Tools/Labour) 46

OSA-EAI Open Object Registry Management ► Enterprise – the corporate level of an organization, or the top organizational structure of a non-profit or military body. Each Enterprise is associated with exactly one Enterprise Type. An enterprise uniquely registers/births Sites and may control one or more Sites (which could have formerly been controlled by other enterprises). In order for multiple enterprises to exchange MIMOSA information, every Enterprise must request and utilize its unique, unchanging MIMOSA-assigned Enterprise Unique Integration Code (Enterprise. UIC) ► Enterprise Type – a kind of Enterprise, ex. "Corporation" ► Enterprise Unique Integration Code (Enterprise-UIC) – the MIMOSAassigned unique identifier of an Enterprise. A globally-unique, nonnegative, non-repeating integer assigned to an Enterprise through MIMOSA's Enterprise Unique Integration Code Registry Service. September 2008 47

OSA-EAI Open Object Registry Management ► Enterprise Unique Integration Code (UIC) – The OSA-EAI Enterprise UIC is a 4 -byte, non-negative integer assigned by MIMOSA for Open. O&M. Normally, MIMOSA will issue one enterprise GUID per corporation/organization. For some organizations, multiple enterprise GUIDs may be requested. – MIMOSA will also assign the enterprise with a globally-unique, alpha-numeric user_tag_id value. This can be used in conjunction with the USER_TAG_IDENT column in the site table to form a globally unique text string – A representative from the registration authority for an organization should e-mail the Open. O&M Enterprise Registrar at info@mimosa. org with the name of the organization, requested USER_TAG_IDENT point of contact name, title, phone number, and e-mail address – The Open. O&M Enterprise Registrar will then assign the enterprise GUID and enterprise USER_TAG_IDENT and return this nonnegative integer and associated 8 -byte string to the point of contact. – MIMOSA is the enterprise with a Enterprise UIC of 0 and user_tag_ident value of “MIMOSA”. September 2008 48

OSA-EAI Open Object Registry Management September 2008 49

OSA-EAI Open Object Registry Management September 2008 50

OSA-EAI Open Object Registry Management September 2008 51

OSA-EAI Open Object Registry Management ► Site – an enterprise-defined object (manufacturing plant, facility, platform, fleet object). Each Site is associated with exactly one Site Type. Sites uniquely register/birth Segments, Assets, Agents, Databases, and Measurement Locations. For facility applications, the “Site” can normally represents either the “as-designed” model of a building or the “as-built” building. For industrial and manufacturing applications, this entity normally represents the “as-designed” model of a physical plant or the “as-built” tangible plant. For fleet applications, this entity normally represents the “as-designed” model of a “mobile platform” (truck, vehicle, aircraft or tank) or the “as-built” tangible platform. Each Enterprise uniquely assigns every Site its unique, unchanging Site Unique Integration Code (Site-UIC). ► Site Type – a kind of Site, such as a "Facility" or "Fleet object" ► Site/Site Type Child Structure – a taxonomy of Site Type classifications which have a "super-class" (ex. "Facility") which may be sub-divided into "sub-classes" (ex, "Facility, Office Building", "Facility, Manufacturing Plant", etc. ) ► Site Template – a logical Site which can be utilized as a prototype for physical Site instances. September 2008 52

OSA-EAI Open Object Registry Management ► Site Unique Integration Code (Site-UIC) – the Enterprise-assigned unique identifier of a Site. Because of multiple methodologies for site/plant/platform identification in different industries and in various computer systems, a Site will often need to be associated with many identifiers relevant to the Site because they are the site's "unique key" for various databases. These identifiers may change as a Site is sold, transferred, or its role changes in relationship to multiple other Sites or Enterprises. Because of this requirement, MIMOSA-compliant systems require that a Site be permanently assigned one and only one Site Unique Integration Code which is composed of the birth Enterprise Unique Integration Code concatenated with a site-unique, non-negative integer (in CRIS, the "site_id") which should never change throughout the lifetime of the Site. This Site Unique Integration Code (Enterprise Unique Integration Code + "site_id") normally does not have any external end-user meaning, but is the vital link for all MIMOSA-compliant systems to properly integrate and associate information to the correct Site. The identical Site Unique Integration Code must remain permanently-unique for the life-time of the Site, even though it will most likely have additional temporarily-unique identifier tags assigned to the Site by various systems. September 2008 53

OSA-EAI Open Object Registry Management September 2008 54

OSA-EAI Open Object Registry Management ►Birth a Site for each platform lifecycle engineering design office which will be generating design databases with functional segments over the life of a model of a platform ►Birth a Site for each “end-item” platform where as-built/asmaintained configuration needs to be tracked over time September 2008 55

OSA-EAI Open Object Registry Management ► Database (Data Archive / Site Database) – a repository of MIMOSA data or information at a Site. A Database is associated with exactly one Site. A Site uniquely assigns a Database Unique Integration Code (Database-UIC) to new Databases ("births" Databases). Among other information, customer and supplier Databases identify reference "type" data pertinent enterprise-wide, site-wide, supplier product-wide, or applicable to this site only. MIMOSA publishes Databases with reference data of international or enterprise-to-enterprise applicability (see CRIS Reference Data Library). The reference "type" data includes Enterprise Types, Asset Types, Segment Types, Agent Types, Manufacturers, Measurement Location Types, and Segment/Asset Event Types ► Database Unique Integration Code (Database-UIC) – the Site-assigned unique identifier of a MIMOSA-compliant Database. MIMOSA-compliant systems require that a Database be permanently assigned one and only one Database Unique Integration Code which is composed of the birth Site Unique Integration Code (in CRIS, the "db_site") concatenated with a siteunique, non-negative integer (in CRIS, the "db_id") which should never change throughout the lifetime of the Asset. This Database Unique Integration Code (Site Unique Integration Code + "db_id") normally does not have any external end-user meaning, but is the vital link for all MIMOSA -compliant systems to properly integrate and associate information to the correct Database. The identical Database Unique Integration Code must remain permanently-unique for the life-time of the Site, even though it will most likely have additional temporarily-unique identifier tags assigned to the Database by various systems. September 2008 56

OSA-EAI Open Object Registry Management September 2008 57

Best Practice Use of Database in Fleet Applications ►Birth a Database for each platform life-cycle engineering design office which will be generating design meta-data over the life of a model of a platform ►Birth a Database for each “enditem” platform where information will be locally cached/stored September 2008 58

OSA-EAI Open Object Registry Management ► Manufacturer/Maker – the organization which designs Models of Assets and "Makes" Assets. Databases assign each Manufacturer entry with a unique, unchanging Manufacturer Unique Integration Code (Manufacturer-UIC). ► Model (Make-Model / Manufacturer Product / Manufacturer Part) – identifies a class or sub-class ("model revision" or "lot") of a Manufacturer's products as defined by a manufacturer, of which only one instance can be associated with a specific Asset. Each Model is associated with exactly one Asset Type. A Model can be associated with a top-level Segment which can then be referenced any many Networks which can define the as-designed functional segment structure. ► Model Child Structure – a taxonomy of a manufacturer's product Model "class" (ex. AH-64) which has revision "releases" (ex. "AH 64 A" ) and/or may be sub-divided into "lots" (ex, "AH-64 A Lot 1") which vary in some way from the "parent" Model. September 2008 59

OSA-EAI Open Object Registry Management September 2008 60

OSA-EAI Open Object Registry Management September 2008 61

OSA-EAI Open Object Registry Management ►An OEM life-cycle engineering design office database should birth the Model and Model Child relationships. ►Store model-specification data and nameplate data in Model. Numeric. Data, Model. Character. Data, and Model. BLOBData September 2008 62

OSA-EAI Open Object Registry Management ► Segment (Functional Area Entity / Breakdown Structure Entity) – Associated with a Model – as-designed functional area or breakdown structure entity for a Model. Each Model-associated Segment is associated with exactly one Segment Type. These segments would normally appear on the engineering drawings of the model. The Segment can be decomposed into one or more Segment Child Structures, which are child Segment functional locations inside the parent Segment. The Segment can have multiple Segment Network Structures defined. A Model-associated Segment can have as-designed Measurement Locations. – Associated with an Asset – as-built/as-maintained functional area or breakdown structure entity for a serialized Asset. Each Asset-associated Segment is associated with exactly one Segment Type. These segments might initially be identical to the Model's Segments, but may be changed to be unique for this particular Asset. The Segment can be decomposed into one or more Segment Child Structures, which are child Segment functional locations inside the parent Segment. The Segment can have multiple Segment Network Structures defined. An Assetassociated Segment can have as-built/as-monitored Measurement Locations. An Assetassociated Segment can have serialized Asset component parts installed over time, tracked by Asset Utilization History. ► Segment Child Structure – Dependent decomposition of Segments into multiple subsegments (child segments) to form a single breakdown structure. Only recommended in fleet applications such as paper forms where there is only 1 Segment composition structure September 2008 63

OSA-EAI Open Object Registry Management ► Segment Type – a kind of Segment (ex. "Rotor") which has an associated unchanging, unique Segment Type Unique Integration Code which can be referenced universally and used in Segment Type Child Structures ► Segment Type Child Structure – a taxonomy of Segment Type classifications which have a "super-class" (ex. "Rotor") which may be sub-divided into "sub-classes" (ex, "Rotor, Front" and "Rotor, Tail") ► Segment Unique Integration Code (Segment-UIC)– the Site-assigned unique identifier of a Segment. Because of multiple methodologies for functional location identification in various computer systems, a Segment will often need to be associated with many identifiers relevant to the Segment because they are the segment's "unique key" for various databases. Because of this requirement, MIMOSA-compliant systems require that a Segment be permanently assigned one and only one Segment Unique Integration Code which is composed of the associated Site Unique Integration Code (in CRIS, the "segment_site") concatenated with a site-unique, non-negative integer (in CRIS, the "segment_id") which should never change throughout the lifetime of the Segment. This Segment Unique Integration Code (Site Unique Integration Code + "segment_id") normally does not have any external end-user meaning, but is the vital link for all MIMOSA-compliant systems to properly integrate and associate information to the correct Segment. The identical Segment Unique Integration Code must remain permanentlyunique for the life-time of the Segment, even though it will most likely have additional temporarily-unique user identifier tags assigned to the Segment September 2008 64

OSA-EAI Open Object Registry Management ► Network - the unique identification of a Segment Network Structure and/or an Asset Network Structure for a given database ► Model’s Segment Network Structure - defines connectivity relationships between segments, and allows segments to be associated in ordered input-output flow chains (i. e. , process flowcharts) or sequenced parent-child relationships. These networks are useful for associating segments into Breakdown Structures useful for maintenance, system engineering, operations, logistics, diagnostic/prognostic systems, etc. A Segment can be specified in an unlimited number of Networks. September 2008 65

OSA-EAI Open Object Registry Management September 2008 66

OSA-EAI Open Object Registry Management September 2008 67

OSA-EAI Open Object Registry Management September 2008 68

OSA-EAI Open Object Registry Management ► Birth a segment which represents the entire model and associate it with the Model ► Create segments for each functional grouping area in a platform including LRU locations, and software/firmware locations ► Create Measurement Locations associated with each segment where monitoring will occur ► Store model-specification data and nameplate data in Model. Numeric. Data, Model. Character. Data, and Model. BLOBData ► Create a Network with Segment. Network. Connect entities for each model configuration and associate it with a Model using Model. Valid. Network. History (which tracks changes to the configuration of the Model over time) September 2008 69

OSA-EAI Open Object Registry Management ► Asset – a physical, non-intelligent instantiated object. An Asset may be an entire facility, an entire functioning system (such as an CH-47 Tail Number XYZ helicopter), or a component piece of equipment, such as a specific instance of a bearing. Each Asset is associated with exactly one Asset Type. An Asset can be associated with a top-level Segment which defines its internal as-built/as-maintained functional segment structure. A component Asset may be installed on/at a Segment over a period of time (asset tracking). An Asset can be monitored via Measurement Locations, be associated with work, and may be composed of one or more Asset Child Structures. When first referenced in a MIMOSA-compliant system, an origination Site permanently assigns an Asset Unique Integration Code. ► Asset Child Structure – a breakdown of assets into sub-asset components (child assets), to form serialized component part breakdown trees ► Asset Network Structure - connectivity relationships between assets, and allows assets to be associated in ordered input-output flow chains (i. e, process flowcharts) or sequenced parent-child relationships ► Asset Type – a kind of Asset or Model (ex. "Motor, AC") which has an associated unchanging, unique Asset Type Unique Integration Code which can be referenced universally and used in Asset Type Child Structures September 2008 70

OSA-EAI Open Object Registry Management ► Asset Type Child Structure – a taxonomy of Asset Type classifications which have a "super-class" (ex. "Pump") sub-divided into its "sub-classes" (ex. "Pump, Centrifigual" and "Pump, Axial") ► Asset Unique Integration Code (Asset-UIC) – the Site-assigned unique identifier of an Asset. Because of multiple methodologies for serialized asset/component tracking identification in different industries and in various computer systems, an Asset will often need to be associated with many identifiers relevant to the Asset because they are the asset's "unique key" for various databases. These identifiers may change as an Asset is sold, leased, or refurbished and moves throughout multiple Sites or Enterprises. Because of this requirement, MIMOSA-compliant systems require that an Asset be permanently assigned one and only one Asset Unique Integration Code which is composed of the birth Site Unique Integration Code (in CRIS, the "asset_org_site") concatenated with a site-unique, non-negative integer (in CRIS, the "asset_id") which should never change throughout the lifetime of the Asset. This Asset Unique Integration Code (Site Unique Integration Code + "asset_id") normally does not have any external end-user meaning, but is the vital link for all MIMOSA-compliant systems to properly integrate and associate information to the correct Asset. The identical Asset Unique Integration Code must remain permanently-unique for the life-time of the Asset, even though it will most likely have additional temporarily-unique identifier tags assigned to the Asset by various systems. September 2008 71

OSA-EAI Open Object Registry Management ► Network - the unique identification of a Segment Network Structure and/or an Asset Network Structure for a given database ► Asset’s Segment Network Structure – Specific for an asset, defines connectivity relationships between segments, and allows segments to be associated in ordered inputoutput flow chains (i. e. , process flowcharts) or sequenced parent-child relationships. These networks are useful for associating segments into Breakdown Structures useful for maintenance, system engineering, operations, logistics, diagnostic/prognostic systems, etc. A Segment can be specified in an unlimited number of Networks. September 2008 72

OSA-EAI Open Object Registry Management September 2008 73

OSA-EAI Open Object Registry Management September 2008 74

OSA-EAI Open Object Registry Management September 2008 75

OSA-EAI Open Object Registry Management ► OEM should birth the Asset with its Asset-UIC and associate it with the proper Model. If the OEM does not assign, then must be birthed at first organization receiving the part. ► For platform Assets, create a Site and replicate all the Segments from the previously-created Model networks, including a top-level Segment equivalent to the entire platform. Create a link to this Segment from the Site and the Asset. ► For platform Assets, create Networks with Segment. Network. Connect entities from previously created Model networks for each asset configuration and associate it with an Asset using Asset. Valid. Network. History (which tracks changes to the configuration of the Asset over time) ► Store Asset-specification data and nameplate data in Asset. Numeric. Data, Asset. Character. Data, and Asset. BLOBData September 2008 76

OSA-EAI Open Object Registry Management ►Is it an Asset? – An object is an Asset if it meets one of these criteria: • Could be depreciated in a financial system • Could be tracked by serial number • Could be transferred/sold and utilized/installed at a different Segment possibly associated with another Site at another Enterprise September 2008 77

OSA-EAI Open Object Registry Management ►Is it a Segment? – A functional location where various Assets can be installed over time – Are associated with a Model of a component or a design of an entire process or platform September 2008 78

OSA-EAI Open Object Registry Management ► Agent – a physical, intelligent instantiated object (person, group, organization, or intelligent agent software) which can perform work, make diagnoses, health assessments, etc. Each Agent is associated with exactly one Agent Type. When first referenced in a MIMOSA-compliant system, an origination Site permanently assigns an Agent Unique Integration Code (Agent-UIC). ► Agent Type – a kind of Agent, ex. "Person" or "Organization" ► Agent Unique Integration Code (Agent-UIC) – the Site-assigned unique identifier of an Agent. Because of multiple methodologies for agent identification in different industries and in various computer systems, an Agent will often need to be associated with many identifiers relevant to the Agent because they are the agent's "unique key" for various databases. These identifiers may change as an Agent has various roles for multiple Sites or Enterprises. Because of this requirement, MIMOSA-compliant systems require that an Agent be permanently assigned one and only one Agent Unique Integration Code which is composed of the birth Site Unique Integration Code (in CRIS, the "org_agent_site") concatenated with a siteunique, non-negative integer (in CRIS, the "agent_id") which should never change throughout the lifetime of the Agent. This Agent Unique Integration Code (Site Unique Integration Code + "agent_id") normally does not have any external end-user meaning, but is the vital link for all MIMOSAcompliant systems to properly integrate and associate information to the correct Agent. The identical Agent Unique Integration Code must remain for the life-time of the Agent, even though it will most likely have additional temporarily-unique identifier tags assigned to the Agent by various systems. September 2008 79

OSA-EAI Open Object Registry Management ► In order to guarantee “plug-and-play” interoperable OSA-EAI systems, users and suppliers of OSA-EAI compliant systems must agree to abide by conventions regarding the assignment of Unique Integration Codes (UICs) which are used to guarantee correct identification of objects on every row on every CRIS XML document ► 4 Registration Authorities: – Global Level: MIMOSA • Provides enterprise UIC to corporations/organizations desiring OSAEAI Interoperability and suppliers of MIMOSA-compliant systems – Enterprise Level: Enterprise Administrator • Provides site UIC’s unique for the enterprise – Site Level : Site Administrator • Provides segment UIC’s, agent UIC’s, database UIC’s, and measurement location UIC’s unique for site. – Database Level : Database Administrator • Provides network, manufacturer, model, reference type, ordered list, and work management UIC’s unique to a specific database/data source. September 2008 80

OSA-EAI Open Object Registry Management September 2008 81

OSA-EAI Open Object Registry Management Note: Blue highlighted segments are included in both network hierarchies September 2008 82

OSA-EAI Open Object Registry Management Note: Dark green segments are “leaf” segments where serialized assets can be installed September 2008 83

OSA-EAI Open Object Registry Management Motor P/N AB-C 800 S/N: 4324 September 2008 84

OSA-EAI Open Object Registry Management September 2008 Motor P/N AB-C 800 S/N: 9432 85

OSA-EAI Open Object Registry Management September 2008 Motor P/N AB-C 800 S/N: 1254 86

OSA-EAI Open Object Registry Management CRIS Representation of Object Registry Common Relational Information Schema (CRIS) Common Conceptual Object Model (CCOM) Terminology Dictionary September 2008 87

OSA-EAI Open Object Registry Management MIMOSA Interface Types MIMOSA Data Categ. Type MIMOSA Support Type MIMOSA Functionality Type Database MIMOSA Interfaces MIMOSA Access Type Enterprise Type Row Status Type Site Segment Child Segment Asset On Segment Asset Model Asset Type Segment Type Manufacturer 1 to many(*) relationship September 2008 Site Database 88

MIMOSA Interface Types MIMOSA Data Categ. Type MIMOSA Support Type MIMOSA Functionality Type Database MIMOSA Interfaces MIMOSA Access Type Site Type Enterprise Type Asset Owner History Site Segment Child Asset On Segment Asset Readiness Type Purchase Condition Type Row Status Type Model Child Asset Model Segment Numeric Data Type Segment Numeric Data Asset Numeric Data Type Model Numeric Data Segment Character Data Type Segment Character Data Asset Character Data Type Model Character Data Segment BLOB Data Asset BLOB Data Segment Type BLOB Content Type BLOB Data Type Model BLOB Data Asset Type Manufacturer Site Database 1 to many(*) relationship Agent September 2008 Agent Type Reference Unit Type Engineering Unit Enumerated 89

OSA-EAI Open Object Registry Management CRIS Meta-Data Reference Data Library CRIS Reference Data Library Common Relational Information Schema (CRIS) Common Conceptual Object Model (CCOM) Terminology Dictionary September 2008 90

OSA-EAI Open Object Registry Management ► OSA-EAI Meta. Data Classification System Enables: – Extensible classification taxonomy system for asset types, segment types, OEM codes, model types, asset nameplate data, and all associated specification/cut-sheet data elements September 2008 91

OSA-EAI Open Object Registry Management ► CRIS Meta-data Classification System – Asset Type Classification Codes • Universal asset type taxonomy • Allows standard querying of common asset types, i. e. , “Bearing, Anti-friction, Roller ” • Site Database-extensible – Segment Type Classification Codes • Universal service segment type taxonomy • Allows standard querying of segment type, i. e, “Rotor Tail Section” • Site Database-extensible – OEM & Model Codes • Facilitates standard manufacturer codes and model information – Segment / Asset / Model Nameplate Data Element Standard Codes • Framework to allow open information transfer between all OEMs and end-users • Standard Engineering Units Related to SI Reference Units September 2008 92

OSA-EAI Open Object Registry Management September 2008 93

OSA-EAI Open Object Registry Management September 2008 94

OSA-EAI Open Object Registry Management September 2008 95

OSA-EAI Open Object Registry Management September 2008 96

OSA-EAI Open Object Registry Management ► Enables permanent & consistent identification of all systems, subassemblies and components ► Facilitates correlated tracking of life-cycle O&M information for: • Service Segments – Functional areas of a platform or system with information tracked for the lifetime of the platform or system • Assets – Cradle to grave serialized component information tracking with OEM and user-defined attributes with segment installation history tracking • Models – OEM model component information tracking with OEM-defined attributes – Agent – An intelligent object (person, group, organization, or intelligent agent software) which makes various types of assessments and can be assigned work to be performed ► Supports all types of physical asset components, systems, platforms, and facilities ► Unlimited functional breakdowns of a model of a platform and a specific platform instance September 2008 97

OSA-EAI Open Reliability Management September 2008 Copyright 2007 MIMOSA 98

OSA-EAI Open Reliability Management September 2008 Copyright 2007 MIMOSA 99

OSA-EAI Open Reliability Management ► Provide a consistent information architecture for managing all physical asset reliability information in an open, distributed, multi-vendor, multi-system environment. ► Based on MIMOSA’s physical asset registry ► Enables continuous improvement throughout system, subassembly and component life-cycles ► Supports enterprise-wide, continuous RCM and FMECA analysis ► Enables enterprise-wide component tracking, including geospatial tracking ► Supports OEM model-specific problem reporting ► Provides information to support spare part optimization ► Incorporates root cause analysis information September 2008 Copyright 2007 MIMOSA 100

OSA-EAI Open Reliability Management ►OSA-EAI Meta-data Classification System – Hypothetical Event Failure Classification Codes • Facilities Pareto analysis of most common failure modes by asset type, by model, and by segment type enterprise-wide September 2008 101

OSA-EAI Open Reliability Management September 2008 102

OSA-EAI Open Reliability Management September 2008 103

OSA-EAI Open Reliability Management September 2008 104

OSA-EAI Open Reliability Management ►OSA-EAI Meta-data Classification System – Event Classification Codes – Measurement Location Type Classification Standard Codes • Framework to allow open information transfer between all OEMs and end-users • Standard Engineering Units Related to SI Reference Units September 2008 105

OSA-EAI Open Condition Management September 2008 Copyright 2007 MIMOSA 106

OSA-EAI Open Condition Management September 2008 Copyright 2007 MIMOSA 107

OSA-EAI Open Condition Management ► Provides a consistent information architecture for managing all physical asset condition management information in an open, distributed, multi-vendor, multi-system environment. ► Based on MIMOSA’s physical asset registry ► Conforms to ISO 13374 standard for Machine Condition Monitoring & Diagnostics ► Manages sensor registry using a general measurement location with a measurement location type ► Manages meta-data, raw data, and computational data from a wide variety of technologies – – – Operational data monitoring Vibration/sound dynamic data monitoring Oil/fluid/air sample analysis Thermographic image analysis Binary large object (BLOB) data monitoring ► Supports intelligent agent diagnostic analysis, prognostic analysis, remaining useful life estimates, future failure mode probabilities September 2008 Copyright 2007 MIMOSA 108

OSA-EAI Open Condition Management September 2008 Copyright 2007 MIMOSA 109

OSA-EAI Open Condition Management September 2008 110

OSA-EAI Open Condition Management September 2008 111

OSA-EAI Open Condition Management September 2008 Copyright 2006 MIMOSA 112

OSA-EAI Open Condition Management September 2008 113

OSA-EAI Open Condition Management September 2008 114

OSA-EAI Open Condition Management September 2008 115

OSA-EAI Open Condition Management September 2008 116

OSA-EAI Open Condition Management September 2008 117

OSA-EAI Open Condition Management September 2008 118

OSA-EAI Open Condition Management September 2008 119

OSA-EAI Open Condition Management September 2008 120

OSA-EAI Open Condition Management September 2008 121

OSA-EAI Open Condition Management September 2008 122

OSA-EAI Open Condition Management September 2008 123

OSA-EAI Open Condition Management Use Case #3 Example: Flow platform O&M data (20, 000 points) from the field to national. There is a normal operation mode for the tank and then there is a diagnostic mode for the tank. If something goes wrong, then they use "diagnostic mode" where all the modules report out after performing bit/byte tests, SRU diagnostic tests, etc. September 2008 124

OSA-EAI Open Condition Management September 2008 125

OSA-EAI Open Condition Management September 2008 126

OSA-EAI Open Condition Management September 2008 127

OSA-EAI Open Condition Management September 2008 128

OSA-EAI Open Condition Management September 2008 129

OSA-EAI Open Condition Management September 2008 130

OSA-EAI Open Maintenance Management September 2008 Copyright 2007 MIMOSA 131

OSA-EAI Open Maintenance Management September 2008 Copyright 2007 MIMOSA 132

MIMOSA Open Maintenance Management September 2008 133

MIMOSA Open Maintenance Management September 2008 134

OSA-EAI Open Capability Forecast Management September 2008 Copyright 2007 MIMOSA 135

OSA-EAI Open Capability Forecast Management ► Provides a consistent information architecture for physical asset capability forecasting based on projected future operating profiles, quality constraints, and time constraints managing all physical asset capability forecasting information in an open, distributed, multi-vendor, multi-system environment. ► Supports operational forecast scheduling and what-if order/mission decision support ► Key enabling technology for the real-time enterprise along with raw material availability, personnel availability, and product storage capability forecasting assessment September 2008 Copyright 2007 MIMOSA 136

MIMOSA Open Systems Architecture for Enterprise Application Integration (OSA-EAI) Open Reliability Management Open Maintenance Management Open Object Registry Management Open Condition Management September 2008 137

MIMOSA Open Systems Architecture for Enterprise Application Integration (OSA-EAI) September 2008 Copyright 2007 MIMOSA 138

MIMOSA Open Systems Architecture for Enterprise Application Integration (OSA-EAI) Architecture Tech-CDE-Services For SOAP Tech-CDE Clients & Servers Tech-XML-Web For Tech-XML-Services HTTP Tech-XML For SOAP Tech-XML Clients & Servers Compliant SOA Application Definitions Tech-Doc Producer& Consumer XML Stream or File Tech-CDE Client & Server XML Stream or XML File Tech-XML Client & Server XML Stream or XML File Compliant Application Service Definitions Tech-Doc CRIS XML Document Schema Tech-CDE Aggregate CRIS XML Transaction Client & Server Schema Tech-XML Atomic CRIS XML Transaction Client & Server Schema CRIS Reference Data Library Common Relational Information Schema (CRIS) OSA-EAI Common Conceptual Object Model (CCOM) OSA-EAI Terminology Dictionary XML Content Definition Meta. Data Taxonomy Implementation Model Conceptual Model Semantic Definitions Technology Types [Tech-] REG (Object Registry Management) WORK (O&M Agent Work Management) DIAG (Diagnostics / Prognostics / Health Assessment) TREND (Operational Scalar Data & Alarms) DYN (Dynamic Vibration/Sound Data & Alarms) TEST (Oil/Fluid/Gas/Solid Test Data & Alarms) BLOB (Binary Data/Thermography Data & Alarms) September 2008 REL (RCM/FMECA/Model Reliability Information) TRACK (Physical Asset Geo. Spatial Tracking Information) 139

MIMOSA OSA-EAI V 3. 3 Release Open. O&M for Industry Use Cases Open. O&M for Industry Interoperability Scenarios Open. O&M for Industry Tech-Doc and Tech-CDE Message Definitions with Relevant Tech-XML Messages For Point-to-Point Web Services For Message Buses Tech-Message Open On-Ramp & Off-Ramp Specification Tech-Doc Producer & Consumer XML Stream or File Tech-Doc CRIS XML Document Schema Tech-CDE Client & Server XML Stream or XML File Tech-CDE-Services SOAP Client & Server Tech-XML Client & Server XML Stream or XML File Tech-XML Atomic Tech-CDE Aggregate CRIS XML Transaction Client & Server Schema Open. O&M for Industry Data Element Dictionaries & Taxonomies Tech-XML-Services SOAP Client & Server Compliant Application Service Definitions XML Content Definition Meta. Data Taxonomy CRIS Reference Data Library Open. O&M for Industry CRIS Business Rules Common Relational Information Schema (CRIS) OSA-EAI Common Conceptual Object Model (CCOM) OSA-EAI Terminology Dictionary September 2008 Implementation Model Conceptual Model Semantic Definitions 140

MIMOSA Specification Development Process Flowchart September 2008 141

MIMOSA Specification Release History Beta Version, Members-only Release Final Version, Production Release September 2008 142

OSA-EAI Distribution ► CCOM UML Model ► CRIS XML Relational Schema – XML ► CRIS Meta-Data Reference Database – XML – SQL Server – ORACLE ► TACOM Reference CRIS SQL Server Database ► Tech-CDE Server for SQL Server / ORACLE ► MIMOSA Information Manager Tech-CDE Client Software September 2008 143

Major Classes of Data and Related Architecture Initial Focus Areas As-Fielded Instance Data As-Designed Reference Data Ontology As-Monitored & As-Maintained Event Data Services Oriented Architecture September 2008 144

Teach Them To Speak the Open. O&M Languages! Enterprise HR, Financial, Materiel, Logistics, & Mission Capability Data ISO 15926 EPC & OEM Engineering Product Design Data & Reliability Study Data Production Optimization, Planning & Scheduling Serialized Asset Registry & Lifecycle Configuratio n Management Data Maintenance System Data P 4 T 2 (problem, plan, people, parts, tools, and time] Control Systems, Plant Data Historians & Plant Asset Health/Safety/Environmental Systems Data September 2008 145

End User/EPC Engineering Data Supported by ISO 15926 • Process/Platform Requirements • Process/Platform Segment “Type” Definitions • Process/Platform Segment “Attribute” Definitions • Process/Platform As-Built Segment Information • Segment Unique Identifier • Segment Type + Attribute + Eng. Unit Data • Process/Platform Segment-Segment Relationships (Lifecycle History) • Hierarchical Breakdown Structures • Process Networks • System Networks • Process/Platform Segment Diagrams (Lifecycle History) • P&ID Diagram • System Network Diagram • Process Flow Diagram September 2008 146

End User/EPC Engineering Data Supported by ISO 15926 • Sensor Design • Process/Platform Sensor “Type” Definitions • Process/Platform Sensor “Attribute” Definitions • Process/Platform As-Built Sensor Information • Sensor Tag Unique Identifier • Semi-static Attribute + Eng. Unit Data Pairs • Process/Platform As-Built Segment-Sensor Relationship • Spatial relationship of sensor to segment • Sensor Networks • Process/Platform Sensor Diagrams • Sensor Network Diagram • System Network Diagram September 2008 147

End User/EPC Engineering Data Supported by ISO 15926 • Engineered Maintenance Packages (“Solution Packages”) • Process/Platform Segment Potential Faults • Process/Platform Segment Pre-defined Maintenance Packages • • Parts Requirements Tools Requirements Personnel Requirements Time Requirements • Process/Platform Segment – Solution Packages Relationship September 2008 148

OEM Model Reference Data Supported by ISO 15926 • Equipment OEM Model/Part Information • Equipment “Type” Definitions • Equipment “Attribute” Definitions • As-Designed OEM Model/Part Information • Model/Part Unique Identifier • Model/Part + Attribute + Eng. Unit “Cut-Sheet” Data • As-Designed Sensor Information • Semi-static meta-data regarding Sensors built into design • As-Designed OEM Model/Part Bill of Material (BOM) Breakdown Structure • As-Designed OEM Model Diagrams • BOM Diagram • CAD Drawing September 2008 149

End User Asset Instance Data Supported by MIMOSA OSA-EAI • Equipment Instance “Serialized Asset” Information • Equipment Instance “Type” Definitions (referenced to ISO 15926) • Equipment Instance “Attribute” Definitions (referenced to ISO 15926) • As-Built Equipment Instance Information • Asset Unique Identifier • Semi-Static Attribute + Eng. Unit “Cut-Sheet” Data Pairs (inherited from ISO 15926 model data) • As-Built Equipment Instance Bill of Material (BOM) Breakdown Structure • As-Built Asset Model Diagrams • BOM Diagram (inherited from ISO 15926 model) • CAD Drawing (inherited from ISO 15926 model) September 2008 150

End User Asset Instance Data Supported by MIMOSA OSA-EAI • Equipment Instance “Serialized Asset” Information (cont. ) • As-Maintained Equipment Instance Information • As-Maintained Equipment Instance Bill of Material (BOM) Breakdown Structure • As-Maintained Asset Model Diagrams • BOM Diagram CAD Drawing September 2008 151

End User Field Engineering Data Supported by OSA-EAI • Process/Platform Field Engineering Modifications • Process/Platform As-Modified Segment Information • Segment Unique Identifier • Semi-static Attribute + Eng. Unit Data Pairs • Process/Platform Segment-Segment Relationships • Hierarchical Breakdown Structure Updates • Process Network Updates • System Network Updates September 2008 152

End User Asset Event Data Supported by MIMOSA OSA-EAI & OPC-UA/MIMOSA • Asset and Segment “Event” Data (Current / Historical) • Operating Events and Associated Data • Usage Events (e. g. , 1000 hours since last lube) • Alarm Notification Events (e. g. , turbine overspeed alarm) • Operating Envelope Events (e. g. , exceedances) • Safety Events and Associated Data • Environmental Events and Associated Data • Maintenance-notification Events (e. g. , request for maintenance) • Work Order Generation / State change • Completed Work • Asset Installed/Removed on Segment (Current & Historical) • Hard Failure Events and Associated Data September 2008 153

End User CBM Data Supported by MIMOSA OSA-EAI & OPC-UA/MIMOSA • Data Acquisition (Current & Historical) • Active Tag Sensor Database Registry with Connections to Segments/Assets and OPC UA Current/Historical Server Locations • On-line Monitoring • Scalar Data • Dynamic Signal-processed Data • Periodic Diagnostic Tests & Measurements • Lab Information Sample Data • Data Manipulation (Current & Historical) • State Detection (Current & Historical) • Health Assessment (Current & Historical) • Prognostic Assessment (Current & Historical) • Advisory Generation September 2008 154

End User Production Reporting Data Supported by Prod. ML • Production Level Reporting • Production Scheduling September 2008 155

Mike Brooks – Chevron Vision • name services • metadata • model maps • abstraction • not proprietary • interoperability June 17, 2008 September 2008 156

Mike Brooks – Chevron Vision 2 1 Open. O&M September 2008 157

Historian System Integration Platform Data Process-modeling & optimization Reconciliation System Data Engineering CAD/CAE Systems Document Management Data Lab Information Management Process Modeling Systems. Data Planning and Dispatch Systems Data Environmental Monitoring System September 2008 Workflow Pre-packaged Adaptors/ Connectors Message Transport Maintenance System Basic Admin Advanced Suncor View -- A Coordinated Approach to Full Integration within the Enterprise Encryption, Audit, Security Adapter Development Kit Integration Administration Message Routing & Brokering Data Mapping & Transformation Message Transportation Data Index Analysis Tools Spreadsheets “Portals” 158

Systems Requiring Interoperability September 2008 159

Systems Requiring Interoperability With Abbreviations ► ► ► ► AHM: Asset Health Management System CMS: Condition Monitoring System DCS: Distributed Control System DEV: Instrumentation & Control Device Monitoring System EAM: Enterprise Asset Management (Maintenance Management) System EH&S: Environmental, Health, and Safety Management System EIS: Engineering Information System (Plant/Process Engineering As-Designed & As-Built Network/Segment/Tag Information, Configuration Management Historian) ► ► ► ► EOM: Event-Oriented Message Bus ERM: Enterprise Risk Management System HIST: Process/Asset Data Historian System HMI: Human-Machine Interface (Operator Console) System MES: Manufacturing Execution System / Production Forecasting & Scheduling System OPM: Operational Performance Modeling & Optimization System ORM: Operational Risk Management System such as EH&S, PSM, AHM, QMS PDM: Product Data Management (As-Designed Product/Part Model Identification and Data Sheets, As-Built Asset identification and Data Sheets) ► ► PORT: Enterprise KPI/Event Portal PSM: Process Safety Management System QMS: Quality Management System REG: As-Installed & Maintained Plant/Process Nework/Segment/Asset/Tag Registry & Configuration Management Historian System September 2008 160

Oil & Gas/Petro. Chem Industry Open. O&M Interoperability Scenarios (Complete View) Open Standards Which Define Data Content for Information Exchange: OAGIS, CIDX ISO 15926 & MIMOSA NOTE: Arrows with Do Not Connect Directly to Another System Publish Information Which Can Be Subscribed to By Multiple Systems B 2 MML & PRODML MIMOSA & B 2 MML MIMOSA OPC Fieldbus (Foundation, Profibus, etc. ) September 2008 161

RFQs & POs (OAGIS, CIDX) Enterprise Risk Management System, Enterprise Resource Planning System & Enterprise KPI/Event Portals ERM ERP RFQ Cost/Delivery Schedule & PO Delivery Status (OAGIS, CIDX) Plant/Process Engineering As-Designed & As-Built Network/Segment/Tag Information, Config. Mgmt. Historians EIS OPM KPIs (MIMOSA & B 2 MML) Detailed Prod. Schedules (B 2 MML) ORM KPIs (MIMOSA & B 2 MML) DCS HMI CBO Advisories Op. Work Status & Work History (MIMOSA) Control/SCADA, HMI, & Historians HIST Control Data (Fieldbus) MES (MIMOSA) Usage Readings (MIMOSA) Planned Asset Unavailability Schedule (MIMOSA & B 2 MML) Significant Actual & Early Warning ORM Events (MIMOSA) ORM Operational Risk Management Systems CBM Advisories (MIMOSA) (EH&S, PSMS, AHMS, QMS) Full-resolution Condition Data & Events (MIMOSA) Current Op. Data & Events (OPC UA DA/A&E) EOM Event-Oriented Message Bus Asset Performance Prediction (B 2 MML & PRODML) Operational Performance OPM Modeling & Optimization Systems Detailed Prod. Performance (B 2 MML) Product/Part Engineering Change Advisories Forecasted Demand (B 2 MML & PRODML) RFQ Cost/Delivery Schedule & PO Delivery Status (OAGIS, CIDX) MES KPIs (B 2 MML) Production Forecasting & Scheduling Systems “As-Designed” & “As-Built” Product/Part Data (ISO 15926 & MIMOSA) Hist. Op. Data & Events (OPC UA-HDA) PORT EAM Enterprise Asset Management Systems CBM/Calib. Schedule (MIMOSA) “As-Installed” & “As -Maintained” Master Maintenance Data (MIMOSA & B 2 MML) Work Status, & Work History (MIMOSA) Maint. KPIs (MIMOSA) CBM/Calib. Work Completed (MIMOSA) Asset Removals & Installations (MIMOSA) Measurements, Events, Inspections, Calibrations, Conditions, Usage, and Sensed O&M Actions CMS O&M Event Monitoring DEV I&C Device Monitoring Portable Monitors (Off& On-line) Online Surveillance Monitors Online Protection Monitors Online Transient Monitors Laboratory Information Management Systems (LIMS) REG Plant/Process “As-Installed” & “As-Maintained” Network/Segment/Asset/Tag Registry & Configuration Management Historians OEM Product Data Mgmt. Systems PDM Production Performance (B 2 MML) Production Orders (OAGIS, CIDX, B 2 MML) RFQs & POs (OAGIS, CIDX) Customers Suppliers Oil & Gas/Petro. Chem Industry Open. O&M Interoperability Scenarios “As-Designed” & “As-Built” Plant/Process Engineering Data (ISO 15926 & MIMOSA) Plant/Process Engineering Change Advisories September 2008 162

Oil & Gas/Petro. Chem Industry Open. O&M Interoperability Top-Priority Scenarios As Determined By Top-Priority Use Cases Open Standards Which Define Data Content for Information Exchange: OAGIS, CIDX ISO 15926 & MIMOSA NOTE: Arrows with Do Not Connect Directly to Another System Publish Information Which Can Be Subscribed to By Multiple Systems B 2 MML & PRODML MIMOSA & B 2 MML MIMOSA OPC Fieldbus (Foundation, Profibus, etc. ) September 2008 163

RFQs & POs (OAGIS, CIDX) RFQ Cost/Delivery Schedule & PO Delivery Status (OAGIS, CIDX) Plant/Process Engineering As-Designed & As-Built Segment/Tag Information, Configuration Management Historians EIS 1 2 3 23 ERM ERP “As-Designed” & “As. Built” Product/Part Data (ISO 15926 & MIMOSA) 28 Op. Work Status & Work History (MIMOSA) OPM KPIs (MIMOSA & B 2 MML) 21 ORM Risk KPIs (MIMOSA & 17 B 2 MML) DCS HMI CBO Advisories Control/SCADA, HMI, & Historians HIST Forecasted Demand (B 2 MML 22 & PRODML) (MIMOSA) 10 11 Usage Readings (MIMOSA) 18 MES ORM Operational Risk Management Systems CBM Advisories (MIMOSA) 12 (EH&S, PSMS, AHMS, QMS) 25 26 Full-resolution Condition Data & Events (MIMOSA) Current Op. Data & Events (OPC UA DA/A&E) EOM REG Event-Oriented Message Bus Asset Performance Prediction (B 2 MML & PRODML) 7 Planned Asset Unavailability Schedule (MIMOSA & B 2 MML) Significant Actual & Early 20 Warning ORM Events (MIMOSA) 19 RFQ Cost/Delivery Schedule & PO Delivery Status (OAGIS, CIDX) MES KPIs (B 2 MML) Operational Performance OPM Modeling & Optimization Systems Detailed Prod. Performance (B 2 MML) Detailed Prod. Schedules (B 2 MML) Control Data (Fieldbus) PORT Production Forecasting & Scheduling Systems Product/Part Engineering Change Advisories Hist. Op. Data & Events (OPC UA-HDA) 27 Production Performance (B 2 MML) Production Orders (OAGIS, CIDX, B 2 MML) RFQs & POs (OAGIS, CIDX) EAM Enterprise Asset Management Systems CBM/Calib. Schedule (MIMOSA) 8 “As-Installed” & “As -Maintained” Master Maintenance Data (MIMOSA & B 2 MML) Work Status, & Work History (MIMOSA) 13 14 15 9 16 Maint. KPIs (MIMOSA) CBM/Calib. Work Completed (MIMOSA) Asset Removals & Installations (MIMOSA) Measurements, Events, Inspections, Calibrations, Conditions, Usage, and Sensed O&M Actions CMS O&M Event Monitoring DEV I&C Device Monitoring Portable Monitors (Off& On-line) Online Surveillance Monitors Online Protection Monitors Online Transient Monitors Laboratory Information Management Systems (LIMS) “As-Designed” & “As-Built” Plant/Process Engineering Data (ISO 15926 & MIMOSA) 24 4 6 Plant/Process “As-Installed” & “As-Maintained” Segment/Asset/Tag Registry & Configuration Management Historians OEM Product Data Mgmt. Systems PDM Enterprise Risk Management System, Enterprise Resource Planning System & Enterprise KPI/Event Portals Customers Suppliers Oil & Gas/Petro. Chem Industry Open. O&M Interoperability Top-Priority Scenarios 5 Plant/Process Engineering Change Advisories September 2008 164

Oil & Gas/Petro. Chem Industry Open. O&M Interoperability Top. Priority Scenarios 1 Pull Model Data Out of PDM to ERM, ERP, PORT, ORM, EAM, EIS, REG, CMS, HMI, HIST 2 Synch Creation/Update of Model Data Out of PDM to ERM, ERP, ORM, EAM, EIS, REG, CMS, HIST 3 Push Model Data Into PDM from ERM, ERP, PORT, ORM, EAM, EIS, REG, CMS, HMI, HIST 4 Pull As-Designed Plant/Process Engineering Network/Segment/Tag Data Out of EIS to REG 5 Synch Creation/Update of As-Designed Process Engineering Network/Segment/Tag Data Out of EIS to REG 6 Push Asset Removal/Installation into REG from CMS 7 Pull Registry Data Out of REG to ERM, ERP, PORT, ORM, EAM, HMI, HIST, OPM, MES, CMS 8 Synch Creation/Update of Registry Data Out of REG to ERM, ERP, EIS, ORM, EAM, HIST, OPM, MES, CMS 9 Push Registry Data Into REG from ERM, ERP, ORM, EAM, HMI, HIST, OPM, MES, CMS 10 Pull Usage Readings Out of HIST to EAM, ORM 11 Synch Creation/Update of Usage Readings Out of HIST to EAM, ORM 12 Push CBM Advisories into EAM from ORM 13 Pull Maintenance Work Status/Work History Out of EAM to ORM, HMI, OPM 14 Synch Creation/Update of Maintenance Work Status/Work History Out of EAM to ORM, HMI, OPM 15 Pull EAM KPIs Out of EAM to PORT, ORM, OPM 16 Synch Creation/Update of EAM KPIs Out of EAM to PORT, ORM, OPM 17 Pull ORM KPIs Out of ORM to ERM, PORT, OPM 18 Synch Creation/Update of ORM KPIs Out of ORM to ERM, PORT, OPM 19 Pull Significant ORM Events Out of ORM to ERM, PORT, OPM 20 Synch Creation/Update of Significant ORM Events Out of ORM to ERM, PORT, OPM 21 Pull OPM KPIs Out of OPM to ERM, PORT, MES September 2008 165

Oil & Gas/Petro. Chem Industry Open. O&M Interoperability Top. Priority Scenarios 22 Synch Creation/Update of OPM KPIs Out of OPM to ERM, PORT, MES 23 Synch Product/Part Engineering Change Advisories Out of PDM to ORM, REG 24 Synch Plant/Process Change Advisories Out of EIS to ORM, REG 25 (OPC UA) Pull Current Operating Data and Events Out of CMS to ORM, OPM, HMI, HIST 26 (OPC UA) Synch Current Operating Data and Events Out of CMS to ORM, OPM, HMI, HIST 27 (OPC UA) Pull Historical Operating Data and Events Out of HIST to ORM, OPM 28 (OPC UA) Pull Historical Operating Data and Events Out of HIST to ORM, OPM September 2008 166

Scenarios Activated by Use Cases September 2008 167

Frequently Asked Questions Q: What version of MIMOSA OSA-EAI should the industry use today? A: Use the latest production release of specifications – Version 3. 2. Q: Does MIMOSA OSA-EAI compliance require a specific physical database structure to be used? A: No. Compliance looks at the resulting XML data in a Web Service to ensure it is compliant with the CRIS XML Schema. Suppliers can choose to physically store their data in optimal ways based on a particular database as long as they can generate the appropriate XML in the end. Q: Does one need to use database replication to exchange MIMOSA OSAEAI data? A: No. In fact, persistence of CRIS data is not even addressed by MIMOSA OSA-EAI, though MIMOSA publishes a meta-data dictionary in XML, ORACLE, and SQL-Server script formats. MIMOSA OSA-EAI defines a common information model “language” which is typically utilized in point-to-point Web Services or used as the information content format in an Information Service Bus. The use of OSA-EAI CRIS XML content in an Information Service Bus has been successfully implemented in the Oil & Gas industry, and is the direction the Oil & Gas industry is moving. September 2008 168

Frequently Asked Questions Q: How does MIMOSA OSA-EAI ensure that data generated by one application does not use the same primary key that another application uses? A: MIMOSA OSA-EAI is a global, peer-to-peer, common information model, assuming a centralized registration authority/service for each enterprise. Each enterprise has control of the process to register its platform/logistic management offices, fleet assets, segments, sensors, networks, and data dictionaries/taxonomies. MIMOSA OSA-EAI only specifies the format of the resulting Unique Integration Codes (UICs), which are universally-unique surrogate primary keys [keys without meaning except for integration]. The use of surrogate primary keys is the best practice in software engineering, since any key with meaning to an end-user could possibly be changed (or entered incorrectly) and subsequently need to be changed--not possible of a primary key. In addition, some assets are keyed differently in different information systems. This drives the need for AMC to have a registration authority in order to provide the method for applications to obtain/derive these OSA-EAI Unique Integration Codes (UICs). September 2008 169

Frequently Asked Questions Q: How does MIMOSA OSA-EAI implement different role-based “views” of a platform asset? A: MIMOSA OSA-EAI allows up to 4 billion different segment breakdown views of an asset (called “Networks”) to be defined and then assigned to a User profile (called “Agent_Roles”). Q: Can MIMOSA OSA-EAI work “out of the box” or does it normally need to be configured with business rules, data dictionaries and taxonomies? A: The latter. MIMOSA OSA-EAI is a “language” which allows you to define standard meta-data, data dictionary entries and taxonomies for a given domain. OSA-EAI has been used to monitor California highways and bridges, sensored stationary manufacturing processes, jet aircraft, and trucks. The entity names in OSA-EAI never change (such as “Asset”), only the meta -data entries (such as those in “Asset_Type”) and the data dictionaries (such as “Asset Character Data Type”) which contain the meta-data relevant for all Assets in a given domain. September 2008 170

Bibliography ► Byrne, John A. , “The Horizontal Corporation, It’s about Managing Across, Not Up and Down”, Newsweek, December 20, 1993. ► Cook, Melissa. Building Enterprise Information Architectures, Reengineering Information Systems, Prentice-Hall, 1996. ► Howard, Philip. Bloor Research, SOA and Information Services: The Information Service Bus, March 2006. http: //www 03. ibm. com/industries/government/doc/content/bin/soa_informa tion_services. pdf ► Hatami, Mehdi. DM Direct, SOA: Providing Enterprise-Wide Information Access, April 2007. http: //www. dmreview. com/dmdirect/20070413/1080889 -1. html ► Zachman, John A. “A Framework for Information Systems Architecture, ” IBM Systems Journal 26, no. 3, 1987. September 2008 171