1 / 50

PIM Model Workshop

PIM Model Workshop. Russell Adams EPRI Bob Renuart UniStar. EPRI PIM WORKSHOP AGENDA. Screenshots EPRI PIM Model Live Demo How will a Utility develop CMIS with an “Imperfect Start”? Next Steps. Screenshots EPRI PIM Model. PIM Features – Object Screen. Selected Object.

giacinto
Download Presentation

PIM Model Workshop

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PIM Model Workshop Russell Adams EPRI Bob Renuart UniStar

  2. EPRI PIM WORKSHOP AGENDA Screenshots EPRI PIM Model Live Demo How will a Utility develop CMIS with an “Imperfect Start”? Next Steps

  3. ScreenshotsEPRI PIM Model

  4. PIM Features – Object Screen Selected Object Lifecycle Views Parents,Children,Siblings Relationships CM Taxonomy Object Attributes Attribute Related Items Industry References

  5. PIM View – Dynamic Reports Selected Object….

  6. PIM View – Dynamic Radial Diagram Selected Object….

  7. PIM Example – CM Taxonomy Relationships View Parent, Children, Sibling Relationships Selected Object CM Taxonomy

  8. PIM View – Dynamic CM Taxonomy View Selected Object….

  9. PIM View – Dynamic Tree

  10. Live Demo

  11. How will a Utility develop CMIS with an “Imperfect Start”?

  12. How will a Utility develop CMIS with an “Imperfect Start”? • Designate a Core Team that is Empowered to provide input for each Department • Make Decisions on: • Level of Requirements to track at a data level that will be related to design data. • Data to be managed in CMIS – CM at the Data Level has an overhead. • What data should be “published” into CMIS after the plant goes operational. • Establishing Relationships, types of Relationships • Certifying Data that is not delivered by the EPC as Configuration Controlled. • Functionality within CMIS • Compile the above Information and Develop a Functional Requirements Spec that will be issued for Bid

  13. Obtain Stakeholder Input to better Define: Department Data Needs that should be Configuration Controlled in CMIS Data Structure Functionality Desired from CMIS Document/Data Relationship Structure Participate in Testing Software

  14. Requirements Tracking in CMIS Defining and Bounding the Scope of Requirements is the Labor Intensive Part. This has to be done first. One Approach used by a New Build: Identify Requirements to the numerical paragraph level in the DCD, COLA, Other Licenses and Permits etc., that contain Quantitative Licensing Basis Values and establish Relationships to the SSC Tag Object.

  15. Example of a Quantitative Requirement for CCW in the DCD

  16. Another Example

  17. Requirements Tracking in CMIS • Leveraging CMIS can: • Provide traceability to where the Requirement is implemented in the EPC Lifecycle • Identify if a Requirement may be affected by a Design Change by establishing Relationships to affected Documents/Data • Identify what Design may be impacted if a Requirement is changed.

  18. Bounding Data Managed in CMIS • Managing CM at a Data Level requires additional “overhead” • A typical Pump Data sheet has 100-150 attributes. In reality only about 25 need to be in CMIS at the DATA level (the Pump Data Sheet will still be available as a configuration controlled Document linked to the Tag Number and retrievable within CMIS). • How Decide? New Build practice is to predefine Attributes for each Object Class that: • Defines the Design Basis of the Objects • Supports Equipment Reliability • Is used in Maintenance Rule, PRA, DRAP • Is Operations Critical • Contains Data used in more than one application (i.e., is in the “hub” of the Flower Diagram showed earlier) EXAMPLE. Work Control and the ISI Program require access to Weld Numbers, and Weld Attributes for SR Systems • Contains Data that has no formal controlled database to manage CM • CMIS will be Extensible so that more content can be easily added. Goal is to start with a Compact, high use data set and add later as value is realized

  19. Building Relationships Many Document to Tag and Tag to Tag Relationships are built in the EPC 2D and 3D model. These relationships can be Inherited into CMIS Many Document to Tag Relationships can be Inherited from the Document Number, i.e., System Number, Building Number, etc. Consider Electronic Extraction of Tag and Document Numbers in the content of a document. Document to Document Relationships for the most part have to be Manually Created. Experience shows it takes an average of 10 minutes per document to open, review, identify, and record relationships. This could likely be cut in half with Electronic Extraction.

  20. Establishing Quality Control Standards for Data Managed in CMIS • Data imported from the EPC Master Equipment List (MEL) should have high integrity. • Data imported from other sources should have a “recent,” approved PDF version that validates integrity. • Data that doesn’t fall into the above, may require revalidation before use in an Appendix B Application. • Caution: Don’t assume all the data in the 2D/3D models is Configuration Controlled • Use a Graded Approach for Data Change Control, e.g., • Data that represents the Design Basis, full Appx B • Data that is important to Plant Operations, but not part of the Design Basis, a lower level of control • Data that is purely Administrative. Admin Control • Tags, like documents, should carry Revision Level that changes whenever the attributes of the tag change.

  21. Revalidating Data that has not been Configuration Controlled Data Objects will be assigned Status Codes and Revision Levels in CMIS. The Status Code will Caution the End-User re Integrity. Once the End User validates, the Status Code will change. This can be an ongoing process.

  22. Next StepsEPRI PIM Model

  23. Next Steps -Industry Working Group Teams

  24. Industry Working Subgroup Teams • Team 1 • Finalize Relationship Choices • Finalize CM Taxonomy Model • Identify CM Taxonomy Model Standard Relationships • Team 2 • Handover DocType Groups and Lifecycle Stages • Standard Set of Document Types and their related Doctype Group • Attributes for Configuration Information Management • Team 3 • Identify and Leverage Results From Current NNPP Projects Document Relationships Initiatives • Develop CM Taxonomy for Regulatory & Industry Codes that all US NNP Must Comply With

  25. PIM Handover Standard – Record & Document Types

  26. PIM Feature – Inherited Object Attributes

  27. PIM Feature – Inherited Object Attributes

  28. Under Construction • Discuss Kickoff of Industry EPRI PIM Working Group Teams to • Populate Standard Handover Framework for Documents and Data (Content) • Populate Standard Configuration Management Taxonomy Reference Model (CM)

  29. Next Steps -Industry Adoption

  30. Industry Adoption – Why? Industry Team Participation Incorporate the EPRI PIM Standard for Handover and Configuration Information Management into ISO 15926 Adopting EPRI PIM will Lead to More Standardized Hanover Specifications, Solutions and Software Applications/Systems Resulting in Cost and Time Savings by Reducing the Difficulty in Expressing and the Ambiguity in Interpreting Handover Content Handover of Quality Information will occurs Timely and Seamlessly as Content that is Interrelated with Logical, Traceable, Reproducible and Manageable Relationship Connections between Requirements and SSCs

  31. Next Steps -Software Solution Vendor ?

  32. Intergraph’sAdoption & Endorsement of PIM Keith Denton Intergraph

  33. Intergraph SP CMIS with EPRI PIM ModelLive Demo Kevin Gribbin Intergraph

  34. IBM’s Rational Modeling of EPRI PIM Darrell Schrag IBM

  35. EPRI PIM Model – Join Us Thank you

  36. CMIS SSC Taxonomy for EPC

  37. CMIS SSC Taxonomy for EPC Requirements Engineered Item

  38. CMIS SSC Taxonomy for EPC Engineered Item Requirements

  39. CMIS SSC Taxonomy for EPC Requirements Engineered Item

  40. CMIS SSC Taxonomy for EPC Requirements Engineered Item

  41. Data/Document/Relationship Development Lifecycle Requirements Engineered Item Procured Item

  42. Requirements Engineered Item Procured Item Installed Item

  43. Ambiguity? RATED DIFFERENTIAL HEAD ISO 15926 Total Developed Head DIFF. HEAD INPO Centrifugal Pump Model American Petroleum Institute API Data Sheet PMP DESIGN HEAD Differential Head Rated AP1000 BG SUDS Process Industry Practice (PIP Data Sheet) Differential Head, Rated HI EDE Standard Same Data - different terminology and format

  44. Conceptual Configuration Information Management System Model

  45. Conceptual Configuration Information Management System Model

  46. Conceptual Configuration Information Management System Model

  47. Conceptual Configuration Information Management System Model

  48. CMIS will be the “Information Hub” of the Operating Plant Lifecycle Management System

More Related