Classes
Classes group similar technical information, are owned by a
standard and are the primary
sorting function within IFS/Asset Design. A process design system has separate classes
created for pumps, motors, pipes, heat exchangers, instruments, tanks and cables,
among others.
Each class contains similar technical information, guides permissible relations and
display properties, and controls the functionality and behavior of IFS/Asset
Design.
IFS/Asset Design employs two types of classes: design object and
design part.
Design object classes are created first and design part classes are created
afterwards to mirror the object classes. The parallel design part-design object
class structure simplifies the process of relating the design parts to their
object counterparts.
Most of the important design object, design part, and
system settings occur on a per-class basis. Class relations determine the
allowed interaction between the objects and design parts. Class properties set
the appearance and behavior within a Tree View on the
Business Object Explorer for objects and design parts.
Class Components
Each class is comprised of (and/or influenced by) the following
parts:
- Class Name/Identifier - mandatory
- Type of Class (design object and/or design part) - 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
- Design Part Codes - optional
Creating 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 design parts and
would logically have similar positions within a system or process. For
instance, pumps
are connected to motors, have design parts of pumps 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 and
design parts. 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
and design part classes depending on the key fields for the model and the
type of design object or design part which will be created from the
connected 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.
- Classes sort alphabetically within a Tree View on the Business Object Explorer. Prefixes can be added to
affect the sort order. For example, adding the + sign as a prefix to several
classes
groups them together.
- 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 the
Business Object Explorer.
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 objects and
design parts)
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.
Design Part Class Considerations
Design part classes are created after their corresponding design object classes have
been created,
and they will be given the same names as the design object classes. For example, the
design object class, PUMP,
and the design part class, PUMP. Class relations will connect the two classes, such that the
design part members in the PUMP class are related to the object members in the
design object 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 Class
A default class structure exists to enable the creation of the objects without
defining a class. The default class is particularly valuable during the Asset Design process
when the construction database is being populated with 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.
Viewing a Class folder
For a class folder to appear within a Tree View on the Business Object Explorer,
the class
must be configured, the tree view must be configured to display the class, and an object or design part must be registered within that
class. Classes usually form the basis for navigational structures.
Setting and Clearing Entity-Type Class Definitions
A class that is set as a design object class and/or design part class
in the
Class window and then cleared of this definition, no longer allows the
registration of objects or design parts 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.
Objects or design parts belonging to a class for which the entity-type
definition has been cleared are still visible within
the Business Object Explorer, but further registration to that class is prohibited.
Changing Design Object Class
A design object class can be changed from a design object tree view on the
Business Object Explorer and all
object
windows using a right mouse 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).