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

A-EDM SeminarA-EDM Seminar

TEF Schema Introduction(6)

Contents

23. EF Architectural Model

24. Schema “Evolution”

25. Schema Reading Practice

26. Secrets of the SmartPlant schema

Master

23.EF Architectural ModelThe 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

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!

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?

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” modelIt is in the “Equipment Data Sheet” Component SchemaIt has a Primary interface

UML Reading Practice for InterfaceDefsFigures 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

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?

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.

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.

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 EnumListLevelTypeHow 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.

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

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)

Thank you