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.

Parent Class

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