Classes
Classes group similar design and technical information.
They are always owned by a standard and are the primary sorting function within
Asset Design. A process design system has related classes created for pumps,
motors, pipes, heat exchangers, tanks and cables, among others. Similarly, electrical,
instrumentation and piping design systems will have their own set of classes.
Each class contains similar technical information, guides permissible relations
and display properties, and controls the functionality and behavior of Asset
Design:
- Asset Design employs design object and design part class.
- PDM employs engineering part class.
Most of the important design object settings occur on a
per design object class basis, as defined in Asset Design/Class Basic
Data pages, for example:
- Class relations determine the allowed interaction between design objects.
- Class properties set the appearance and behavior within Design
Object pages.
Engineering part settings occur on per part class basis
as defined in PDM/Basic Data/Part Classes page, for example:
- Document requirement that must be fulfilled before the engineering part
can be released.
Design Object Class Components
Each design object class is comprised of (and/or influenced
by) the following:
- Class Name/Identifier - mandatory
- Class Parent Structure (enables change class functionality) - optional
- Discipline (mechanical, electrical, instrument and process) - optional
- Object Copy Inheritance fields - optional
- Class Relations - optional
- Class Properties - optional
- ID Models - optional
- Technical Data - optional
Engineering Part Components
Each design object class is comprised of (and/or influenced
by) the following:
- Class Name - mandatory
- Document requirement - optional
- Technical Data - optional
Creating Design Object Classes
The most important considerations for the creation of a
class are:
- Technical Data - For example, pumps share similar technical data and
would logically be placed in the same class. The same is true of motors,
heat exchangers and switchgears. A motor and a pump would not be placed
in the same class because of their dissimilar technical data. Technical
data templates are created to list the attributes for a certain class. Information
is entered based on these attributes.
- Class Relations - For example, pumps need to be connected to certain
objects and would logically have similar positions within a system or process. For
instance, pumps are driven by motors and are connected to pipes. These necessary
types of connections are recreated within IFS/Asset Design using class relations.
- Identification model (ID Model) - For example, the individual key fields
of an ID Model may be different for different types of design objects. For
instance, electrical and instrument objects ID fields are often different
compared to those for piping, process and mechanical objects. Therefore
suitable ID Models should be connected to design object classes depending
on the key fields for the model and the type of design object which will
be created from the connected class.
- Equipment Object information - Entering the object type and object level
enables the transfer of a design object created from a class to IFS/Equipment.
- Milestone information - Entering the milestone template and milestone
number enables this information to be copied to every object created from
a class.
Class Naming and Sorting Conventions
The following conventions are used when naming and configuring classes:
- A class is given a descriptive name. For example, PUMP, MOTOR and SWITCHGEAR.
In the case of multiple objects of a similar type, a class may receive two
names for easier recognition and sorting purposes. For example, CABLE, GENERAL
and CABLE, CIRCUIT.
- Use letters and numbers to name your classes. Do not use the \,
/, : , *, ?, ", <, >, | characters.
- Classes can be named by discipline. For example, the class EL MOTOR
can be created to hold functional electrical motor objects associated with
the electrical discipline. The class MECH CENT_PUMP is created to hold functional
centrifugal pump objects associated with the mechanical discipline.
- A class can be set up to allow free functional and/or free locational
relations. Class properties enable you to display a functional and/or locational
structure on a Tree View in Explore Design Objects.
Design Object Class Considerations
Design object classes are created before adding the member objects. Often
the class name (or an abbreviated version of it) will be part of the object
ID. It is easier to create the unique object IDs if the class designation already
exists.
When setting up object class names, the object's technical data and ID designations
should be considered as follows:
- Technical Data - This includes materials, power and input/output, among
others. Consider what the technical data for a group is and if it can be
easily shared across similar objects. If all pumps in the design have the
same technical data, create one PUMP class. However, if the design uses
screw pumps and centrifugal pumps, each with unique technical data, it becomes
advantageous or even necessary to create two separate classes: SCREW_PUMP
and CENTRIFUGAL_PUMP. Technical attributes are assigned specifically to
fit each pump class.
- ID Designations - The ID designations (numbering systems for design
objects) can be a deciding factor when creating classes. Consider a facility
that uses instrumentation and telephone cables. The cables share the same
technical data, but use differing ID designations. For example, the instrumentation
cables use a simple cable number, whereas telephone cables use a combination
number (the first part of the number is inherited from its connected
cabinet and the second part is a special cable number). Because of these
ID designation differences, they should not share the same class, although
the two cable types share the same technical data.
Part Class Considerations
Part classes are created after their corresponding design object classes
have been created, and they will usually be given the same names as the design
object classes. For example, the design object class, PUMP, and the part class,
PUMP.
Class Identifier
A class identifier, which is a mandatory designation for each class, is used
to give the class a common name when different sites use local language names
for the class. For example, a class identifier could be set to the English-language
Pressure Vessel. For a site in Sweden, the class name Tryckkärl would be used
and a site in Germany would use the class name Druckbehälter. However, both
sites would use the English-language class identifier Pressure Vessel as a common
class name. The Class Identifier becomes invaluable when comparing, importing
and exporting data between IFS/Asset Design sites in different countries.
Default Design Object Class
A default class structure exists to enable the creation of design objects
without defining a specific class. The default class is particularly valuable
during the early stages of the design when the Asset Design database is being
populated with design objects. The default class structure also has a validation
function that assigns an object to the correct class based on the given parent
object ID.
This default class has the following characteristics:
- The default class is called *, Default. Within the user interface,
this class appears as *.
- The default class is a virtual class and cannot be modified from the
user interface.
- All possible class relations exist for the default class (each class
value has a default of %). For example, the can have a free functional
parent = % class relation, which enables the default class to have all
classes as free functional parent relations.
- All class properties are valid.
- Default ID model and ID separators apply.
- New user-defined relations exist for the default class with % for the
class value.
Setting and Clearing Entity-Type Design Object Class Definitions
A class that is set as a design object class in the
Class page and then cleared of this definition,
no longer allows the registration of objects to it. A class for which the entity-type
definition has been cleared does not appear within Lists of Values and cannot
take part in a class change. Design objects belonging to a class for which the
entity-type definition has been cleared are still visible within Design Object
Explorer, but further registration to that class is prohibited.
Changing Design Object Class
A design object class can be changed from all object pages using a command
button option. A dialog box opens showing the current class. The new class is
then selected from a pull-down list containing available classes. The available
classes are determined by Parent Class.
The following rules apply to object class changes:
- The design object class can be changed only if the object status is
Under Design, Planned for Operation, or ReDesign.
- If the new class does not contain a certain class relation, the relation
is not copied from the current class to the new class. It is very easy to
lose relations if you are not careful when changing classes.
- If the new class does not contain an existing class property (record
type, channels, terminals, nozzles, or wires), the property is not copied
from the current class to the new class.
- All technical attribute data values are copied from the current class
to the new class as long as the same technical attribute exists within both
classes. If the copy operation does not find a corresponding technical attribute
in the new class, an error message is displayed, and the class change can
be continued or cancelled.
- A class change can be applied across multiple objects if the selected
objects share the same class.
- Refer to About ID Models for information on the impact of class change
on ID models and object IDs.
The parent class is defined on the design object class level. The parent
class structure determines if a design object class change is allowed and to
which classes the design object class may be changed. A design object class
without a designated parent class is not allowed a class change.
Parent classes are defined with general class information. For example, Pump
Misc would have a general class configuration applicable to centrifugal and
diaphragm pumps as well as controlled volume and hydraulic pumps. This is important
to avoid conflicts and loss of information, such as technical data, class relations,
and class properties when the object's class is changed.
A temporary class structure can be created to group objects by their probable
class inclusion. Such a structure is created by defining a parent class for
multiple object classes. For example, a generic pump object could be temporarily
assigned to the class, Pump Misc. Later, it can be assigned to the Pump Centrifugal
class, which would be required to have a parent class of Pump Misc.
An object's class with a designated parent class may be changed to the following
accordingly:
- Parent Class - but not if the parent class is *, default (Pump Centrifugal
could change to Pump Misc but Pump Misc could not change to *, default).
- Child Class - any class below the present class.
- Sibling Class - two classes that share a common parent class, but only
if that class is on the lowest level of the structure (Pump Centrifugal
can change to Pump Diaphragm but Pump Misc cannot change to Motor Misc).