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.

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