1. 2006. 11. 17 기술연구소 유소라 사원 A-EDM Seminar TEF Schema Introduction(6)

2. Contents 23. EF Architectural Model 24. Schema “Evolution” 25. Schema Reading Practice 26. Secrets of the SmartPlant schema Master

3. 23.EF Architectural Model  The Underlying “Architectural Model”  SmartPlant schema, it was decided that the data model should be able to serve as an overall model.  the SmartPlant schema is based on some concepts from POSC Caesar.  In general, the SmartPlant schema has a concept of “early-stage design”, which is encompassed by a “facility model”.  Here is the “Facility model”  Evolves into things that get purchased (or fabricated) called a “material model”.  The “facility” isn’t really something that you can put your hand on, it just evolves into something that fulfills it’s requirements.  Here is the “Material model”  “material” is something that we plan to purchase or fabricate  Or something that was refined from the “facility” model, and will be used in a real application

4. 23.EF Architectural Model  Facility and Material Model Summary  somewhere on a simulation diagram ( maybe an early process flow diagram), a “facility” for controlling fluid flow was defined, and a “material item” was drawn on a P&ID. Later, it was purchased from a manufacturer, and we can finally install, test, maintain, and use the valve for a long time.  That’s a Powerful Idea for design reuse!

5. 24. Schema “Evolution”  The SmartPlant schema is not complete.  There are some things that you can do to extend the schema, and some things that you must not do.  a separately-published and highly-technical document “SmartPlant schema Evolution” that states the rules of schema “evolution”.  If a “conforming” change is made.  If a “non-conforming” change is made.  If a customer extends his schema, how will a new schema from Intergraph PPM get re-synchronized with it?  Do schema files and data files have to be forward-and backward- compatible in order to be useful?

6. 25. Schema Reading Practice  UML Reading Practice for ClassDefs  figure 64. in Appendix H  That diagram is what you’ll actually see if you let the SmartPlant Schema Editor create the UML diagram.  It is a “Share Object” in the “Planned material” model  It is in the “Equipment Data Sheet” Component Schema  It has a Primary interface  UML Reading Practice for InterfaceDefs  Figures 65 through 99 in Appendix H(p.168), to see how the data model of an “agitator”  Figure65, 66, 67, 68, 69,70,71,72,73

7. 26. Secrets of the SmartPlant schema Master  Model InterfaceDefs First (Data Normalization)  The most important thing is to think about the “roles” that you will be modeling.  “roles” are presented to the universe by InterfaceDefs.  there can be lots of “roles”, each of which has many properties and relationships to other roles.  The SmartPlant schema helps to control the complexity.  Organizing Lots of Pump Properties  How would you begin to deal with that kind of complexity?

8. 26. Secrets of the SmartPlant schema Master  What’s the Spin on Rotating Items?  Properties of a “rotating item” - Angular velocity - Asynchronous speed - Maximum angular velocity - Rotation direction - Synchronous speed.  these properties “belong” on InterfaceDef “IRotatingItem”, since every rotating item in the universe has either these exact properties, or such a similar set that we can’t tell the difference.  The Result Of “Normalizing” a Pump  Look at the properties of a pump, when they are normalized.  How Interfaces Help to Tame Polymorphism  Ideas about ClassDefs  There’re just a collection of InterfaceDefs.  Naming ClassDefs  ClassDef names with some identifier that groups them with the software tool that publishes them.

9. 26. Secrets of the SmartPlant schema Master  Ideas about Enumerated Lists (including EnumListLevelType)  It is very common for engineering applications to use large lists for classifying objects.  Figure 41.  All good hierarchies come to an end, and it is usually at a “leaf-node”, but that is not a requirement in the SmartPlant schema.  Incomplete Hierarchies.  The SmartPlant schema accommodates tools that don’t, or can’t think about all those pesky hierarchical levels.  SPF has the idea that tools don’t have to populate values for all the levels of a hierarchy when publishing a document.  Each tool just publishes as much as it can, and that’s OK.  Whatever clue you can give to the downstream application, the better.

10. 26. Secrets of the SmartPlant schema Master  Beating Enumerated Lists into Enumeration Hierarchies  Enumerated lists can be combined to form an enumeration hierarchy.  All EnumListType nodes must contain EnumEnums (enumerated list entries) or other EnumListTypes (enumerated lists).  Cutting Across the Grain with EnumListLevelType  How do we omit levels of hierarchy, and yet have a good exchange of data?...  Figure.43  Scoping with an EnumListLevelType  How will we “scope” these properties  Figure 44.

11. 26. Secrets of the SmartPlant schema Master  Class  is “a group of similar things”  is defined by “ClassDef”  Realizes roles (via interfaces)  Object  is “an instance of a class”  has a unique identifier  is published and retrieved in a “document” to SPF  Interface  is “a role, used for grouping properties and form relationships with other interfaces”  is defined by “InterfaceDef”  Implies other interfaces and thus inherits their characteristics

12. 26. Secrets of the SmartPlant schema Master  Property  is “a basic or essential attribute share by all members of a class”  is defined by “PropertyDef”  is ExposedBy Interfaces  is ScopedBy Data Types or Enumerated Lists  Relationship  is “the rules by which two roles interact”  is defined by “RelDef”  Connects roles (Interfaces) to other roles (Interfaces)

13. Thank you