What the heck is a "Schema"?

One of the key elements to full integration is to have a "schema", and enforce some kind of rules
between a "publisher" and a "retriever" of data. It should be simple for two different systems to
talk about something that they have in common, e.g., a motor, a pump, a valve, etc. But it is
really not simple at all. That's because each system has its own idea of what things are, and how
they are used. A "schema" is simply another way of saying "a diagrammatic representation, an
outline, or a model.

Before you can understand the SmartPlant data model, you have to understand some very basic
concepts (if you already know this stuff, please apply for a job in my department).

1. What is "data modeling"?

2. Classification of objects & Data "normalization"
3. Symbolic logic
4. The Data model
A. Basic structures
i. Classes, Interfaces, etc
ii. Relationships
B. Patterns
5. The Meta Schema

The SmartPlant Schema

The SmartPlant schema describes the structure of data passed through SmartPlant Enterprise, along
with its rules. The SmartPlant schema can be hard to understand, but to make it easier to interpret,
the Schema Component exists. That is a set of .dll's that assists the tools with the generation and
subsequent parsing of the XML data. The tool adapter interfaces with the Schema Component (the
main interface point) to read the SmartPlant schema.

SmartPlant Schema Rules

Because SmartPlant Enterprise is intended to facilitate heterogeneous data exchange,
the following rules apply:
- All schema data is defined as part of the SmartPlant schema
- The SmartPlant schema describes everything that goes on in SPF
- A copy of the SmartPlant schema (an XML file) resides on the server
- Component schemas are selective extracts from the SmartPlant schema, and reside
on every client
- All changes are made to the SmartPlant schema and then propagated to the
component schemas.

Lots of Structures The SmartPlant Foundation data model consists of many

structures (see Appendix I) that make it easier for programs to talk to each other.
The SmartPlant schema is an XML file that describes the structure of the XML files
generated by the authoring tools in much the same way as a data dictionary describes
the structure of a database As tools publish documents in XML format, those
documents must adhere to the format defined by the SmartPlant schema to ensure
that the XML data can be loaded into SmartPlant Foundation (SPF), and retrieved into
the other authoring tools. Here are some of the important concepts that we will cover
in this chapter:
- Classes and ClassDefs
-Component Schemas (CompSchema)
- Interfaces and InterfaceDefs
- Properties, PropertyDefs and Property Types (Scoping)
- Enumerated lists
- Units of measure

Overview of the SmartPlant schema Data Model

In the rest of this document, certain graphical conventions are used when creating and
displaying a UML diagram:
• A "Class" is designated by a rectangle
• An "Interface" may optionally be displayed as a circle or a rectangle
• "Associations", a.k.a. "Relationships" are straight lines, which may, optionally, be
dashed-lines.

Generally, two types of diagrams are developed, viz., an "Interface diagram", and a "Class diagram".
Each type tries to present the data model in an interesting, understandable form. Other diagrams
may be created to make it easier to visualize some aspect of the model. All the UML diagrams may
be saved within the SmartPlant schema file and are available upon demand within the SmartPlant
Schema Editor, when the user asks to see it

SmartPlant schema Class / Interface / Relationship Model

The building blocks of the SmartPlant schema are classes, interfaces, and
relationships:
- Classes typically represent real-world objects like instruments, equipment or pipe
runs. Classes are defined by ClassDefs.
- Interfaces are used to tightly bind "roles". Interfaces are defined by
InterfaceDefs.
- Relationships represent the association between two objects. Relationships are
defined by RelDefs.

In SmartPlant schema jargon, ClassDefs "realize" InterfaceDefs. For example, a

Vessel class definition realizes the interface definition labeled ‘IVessel’. The "IVessel"
interface "exposes" properties, such as "RatedVolume". Do you see: the main purpose
of a ClassDef is to expose a group of related interfaces to the world.

Defining an Interface (InterfaceDef)

In the SmartPlant schema, an interface is defined using an "InterfaceDef" (d'oh!). The
"InterfaceDef" is arguably the most important element in the SmartPlant Foundation data model,
because it is the vehicle that lets objects yield up their roles to the universe. Let's just say that you
need to get very familiar with InterfaceDefs

The "InterfaceDef" class definition realizes the "IInterfaceRole" interface

definition. This interface definition exposes two properties: "SpecializationValue" and
"InterfaceIcon".
"SpecializationValue" is an integer property that indicates how specialized the role for
the interface is. The higher the "SpecializationValue" the more specialized the role.
For interface definitions that have a corresponding icon, the "InterfaceIcon" property
identifies the name of this icon

The combination of "SpecializationValue" and "InterfaceIcon" can be used to determine the most
specialized icon for an object.

InterfaceDef - Graphic Representation

First of all, InterfaceDefs can be represented in 2 different ways, depending on what
the data modeler is trying to express:
The <<Stereotype>>
Notice the first line of text <<InterfaceDef>>. That style of printing (in UML terms) is
called "stereotyping." You don't know about it much now, but a stereotype is a
mechanism that is used to categorize an element in some way. A stereotype name is
surrounded by Guillemots << and >>. Stereotypes are used to extend the UML notational
elements, to classify and extend associations, inheritance relationships, classes and
components. Stereotypes are used to create new kinds of modeling elements. That's
one of the reasons that UML is so powerful, it is easily extended. Enough about stereotypes.

Defining a Property (PropertyDef)

In Figure first, you saw that an InterfaceDef exposes some properties to the
universe. In fact, doing a double-take, you should have noticed that there are pairs
(tuples) of values:
- UID=IPumpOcc
- Name=IPumpOcc
- Description=An equipment item for transferring kinetic energy to a fluid
- PropCategory=Equipment
- DisplayName=Pump

What is a Property?
The Guru Googles some expert definitions:
- A property is a basic, or essential attribute shared by all members of a class.
- In philosophy, mathematics, and logic, a property is an attribute of an object; thus a
red object is said to have the property of red-ness.
What is a PropertyDef?

If you tightly-group very-similar properties together ("normalize them"), and expose them to the
universe, it is more likely that someone who is wanting that set of properties will see and
understand what you are trying to do. The little machine that handles the grouping and exposing to
the universe is the InterfaceDef. The little machine that carries the -ness of a property is a
PropertyDef.

"Scoping" a PropertyDef
If we're talking about an inlet on a valve, it has some interesting properties:

Inlet Size
- Maximum Flow rate
- Material of construction
- Orientation-angle
- Description of the valve
- etc.

application knows exactly what we're talking about. More than that, we both need to
understand the possible values that can be entered into those properties. For example:
- Inlet size is expressed a "length"
- Maximum flow rate is expressed as a "flow rate"
- Material of construction is a list of values
- Orientation-angle is expressed as an angle
- Description of the valve is letters and numbers
- etc.

Scoping Examples
In the SmartPlant schema, we say that a PropertyDef is "scoped by" something. That
something defines the "units", or "lists", or "type of thing" that the PropertyDef will
allow to be passed between applications, e.g.,
- With respect to "Inlet size", the values that we agree can be passed between our
applications are length-units. Therefore we "Scope" the PropertyDef "InletSize" with
"LengthUoM", which contains {inches, feet, meters, ...}. o PropertyDef InletSize is
ScopedBy LengthUoM

- With respect to "orientation-angle", we agree that we're going to exchange angles o

PropertyDef OrientationAngle is ScopedBy AngleUoM, which contains {deg, gr, rad, ...}
- With respect to material of construction, I will pick a value from a list, and later on,
I will hand you the list. o PropertyDef MaterialOfConstruction is ScopedBy
EnumListType 'Materials', which contains {Iron, Copper, SS314, ...}

With respect to the Description, o PropertyDef Description is ScopedBy string

Scoping Types
The Guru looks right through you and says "So you see that "scoping" a PropertyDef is
simply the equivalent of restricting data input values to certain "types"?
Another way of GraphDefType
saying it is that
we are reducing
the scope of what
is possible down
to some well-
defined set of
things. Here are
the intrinsic
(built-in) data
types which can
be used for
Scoping
PropertyDefs:
Intrinsic Type
BooleanType IntType
ClassDefViewDefsTyp LinkedListType
e
CompositeStringType ObjectsType
DateTimeType PathDefType
DirectoryFileType PropComparisonsTyp
e
DiscreteUoMListType PropValsType
DocumentType StringType
DoubleArrayType UoMListType
DoubleType URLType
EnumListLevelType ViewPropsDefType
EnumListType YMDType

InterfaceDef / PropertyDef Redux

Finally, the Guru shouts: "You will attain great levels of understanding when you realize
that InterfaceDefs Expose PropertyDefs, which are ScopedBy Property Types!" Let's
try reading Figure 8, a sample schema, and see how we do...
An InterfaceDef, "SampleValveInlet" Exposes 5 PropertyDefs. Each PropertyDef is
ScopedBy a different Property type, and each type shows some of the possible values
that it allows.
Note that in the SmartPlant schema, InterfaceDef names begin with the letter "I", by
widely-accepted convention.