2006. 11. 17 기술연구소 유소라 사원

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

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