Classes and attributes

The AVEVA Unified Engineering conceptual model visualizes the engineering hierarchies or taxonomies. It is a tree structure that represents the inheritance.

Note: The hierarchy supports multiple inheritance for instances where there is a need to inherit from more than one parent.

Classes are broken down by more Specializations of the Class, forming a hierarchy.

For example, a Class of Actuator, the generalization is too simplistic for the number and functions of Actuator in a plant. It is therefore common to have a specific Class, such as Actuator, which in turn may have a further specialization of Electrical Actuator, denoting the actual type of actuator to be managed.

The categorization is based on grouped characteristics of physically similar objects.

In the example, the image focuses on Flow Measurement from the Sensing Element to the Flow Sensor (different types of flow Sensors), then ending at the specific type of flow sensor.

Attributes sit within the classes. The attributes are not unique to the class but can be reused anywhere they are required. As this is based on the physical world, classes are not owned by disciplines, but it is the attributes that are owned by a discipline group. It is possible for a class to only have attributes belonging to one discipline group, or attributes owned by an all-disciplines group, or to not have a discipline group at all. Discipline groups can be any combination of disciplines. At present, it is not possible to assign multiple disciplines directly to an attribute. Ownership is used in interdisciplinary workflows and controlling read and write.

The current AVEVA Unified Engineering Default Configuration not only has physical class branches but also more abstract ones (non-equipment class) to group specific attributes together for examples standards or conditions:

• Operating Conditions

• Design Conditions

• Hazardous Conditions (International Electrotechnical Commission (IEC))/ATmosphères EXplosibles (ATEX))

• Hazardous Conditions (National Electrical Code (NEC) 500)

• Hazardous Conditions (NEC 505/506)

Add classes and attributes

When you add a class or attribute, there are some considerations you should follow:

• Have a referenceable basis.

• Have a description and ensure that the description describes the function of the equipment.

• If possible, base your class or attribute on International Organization for Standardization (ISO) 15926/StepLib/PCA/CFIHOS/API, or other standards.

• Add any standards IDs to assist you with mapping.

• Indicate why the class or attribute is needed, and if you will use the class in a symbol, datasheet, grid, or report.

• Where possible, avoid abbreviations.

• Use proper text. For example, Air Cooled Heat Exchanger.

• Use lowercase characters for prepositions. For example, on, at, and in.

• Do not use plural names. For example, Analyzers should be Analyzer.

• Try to avoid using adjectives to describe the class or attribute.

• Names should be clear and concise.

• Avoid hyphens in names. Only use hyphens to split context.

• Ensure that the new class or attribute is not a duplicate.

  Typical duplicate classes include the following:

  • Air Receiver or Compressed air tank

  • Alarm Function or Soft Alarm

  • Alarm Unit or Annunciator

    Typical duplicate attributes include the following:

  • Max Design pressure or Design Pressure Maximum

  • Nominal Bore or Pipe Size

  • Pressure Rating or Rated Pressure

• The Simulation/Functional/Physical classes are achieved by decorating the most generic classes, simulation items, functional items, and the rest are implicitly engineering items. The following types of object are created:are types of objects created.

  • Simulation item – inherits down the tree.

  • Functional item– the high-level objects that represent a function object. For example, a PFD object. Functional items do not inherit down the tree. Notes and objects can be both engineering and functional items.

  • Engineering Item – the default type of object without decoration.

    The is realised by association can be used to link the expansions of simulation items to functional items and functional items to engineering items.

Classes

When you add a class, it is important to consider the following:

• The groupings are based on common physical characteristics which are inherited down. Try to model the classes based on a physical classification and specialize accordingly.

• Avoid collection classes just for the purpose of inheritance, as they complicate the tree. It is better to reuse attributes and associations.

• The class should be active in the build, meaning it can be instantiated and is not just there for inheritance.

• Use multiple inheritance where necessary for classes that need to inherit from multiple parents, as the physical characteristics require it.

• All classes should lead to one root node.

• If the class has only one child and one parent, and is unlikely to be extended to include more parents or children, consider removing the class.

• When adding a child class with specialization, consider if this adds special attribution that enriches the general class but does not apply to the general class.

• If the generalized class can fulfill all the requirements but a further variation is required, a distinction can be made by adding an attribute, such as type, to give that distinction. For example:

  • Solid and Flexible Wedge

  • Rising and Non-rising Stem

  • Conduit

  • Parallel Slide

  • Knife Gate

  • Penstock

Attributes

When you add new attributes to AVEVA's Default Configuration, you must have a basic understanding of the class classification, as well as which properties or attributes are required:

• Avoid attributes that sit too high up in the hierarchy.

• Avoid including attributes that are ambiguous or create doubt to their usefulness. Attributes should be relevant and useful to the discipline engineer and have a measurable benefit to Design or Operations.

• Ensure that the attributes are associated to the classes.

• Consider the impact of inheritance, and if that attribute should be at that level.

• Ensure that the correct data type is associated to an attribute, especially where Real, String, and Boolean are used.

• Assign a unit of measurement (UoM) if it is applicable.

  It is not possible to assign a UoM to a string. Some attributes may be dimensionless, such as Specific Gravity (SG).

• Assign a discipline group, if applicable. If all engineers are required to edit the attribute, you do not require a discipline group.

• Consider splitting Min and Max attributes into two separate objects. You do not need to split Range attributes.

• Consider the following for the attribute:

  • Requires a List of Values.

  • Holds multiple case values.

  • Synchronizes across linked objects.

  • Stores a tag name.

  • Holds multiple aspects, such as requirement, purchaser, and manufacture information.

  • It is possible to set individual attributes as Function, Physical, or Both.