Classified Objects Configuration - SmartPlant Foundation - IM Update 46 - Help - Hexagon

SmartPlant Foundation Help

Language
English
Product
SmartPlant Foundation
Search by Category
Help
SmartPlant Foundation / SDx Version
10
SmartPlant Markup Plus Version
10.0 (2019)
Smart Review Version
2020 (15.0)

Classified objects are those that have a typing hierarchy that is modeled in SmartPlant Foundation as a classification tree. The classification tree consists of first class objects so that they support relationship management and shortcut menus to the objects that they classify. They can be configuration controlled, enabling different hierarchies in different configurations.

The classification tree is used to expose the SmartPlant integration typing hierarchies. In the SmartPlant Schema, there are Enum typing hierarchies for documents and tags, but this is a rigid structure that cannot be easily modified and rearranged or sub selected for use in projects.

In SmartPlant Foundation, the Enum hierarchies are hidden behind, and related to, a classification tree. The classification trees need a related Enum hierarchy only to support SmartPlant integration because it is the Enum typing hierarchies that are used by the tools, but they are still exposed as classification trees in SmartPlant Foundation for consistency and GUI support.

Interactive business item creation and query is performed in SmartPlant Foundation using the classification tree with the Enum typing set on the objects in the background. SmartPlant integration still publishes documents and tags based on the Enum typing, and when the objects are loaded into SmartPlant Foundation, relationships to the classification tree are created on the fly. There are two separate relationships: one mapping from the classification tree to the Enum hierarchy for interactive use and one mapping from the Enum hierarchy to the classification tree for use by the publish process.

The following functionality can be configured by the classification tree:

  • Different class definitions (ClassDefs) to create or query from each node.

  • Alternative forms for these class definitions.

  • Alternative ENS definitions for these class definitions.

  • Object typing for SmartPlant integration via relationships to the Enum hierarchy.

Each classification tree can potentially classify many business items; for example, one document classification tree can be used to classify many different document classes. Each tree is usually composed of related objects of the same class definition, though that is not a restriction.

There may be more than one family of objects that follow the same classification such as tags, assets, models, and variants. To control the access to these different families of objects, each of these families are configured using a specific relationship to the class definitions that need to be created or queried within that family. Not every node of the tree needs these relationships because this configuration is inherited down the tree. To identify a node of the tree as being valid for a particular family, each family is usually represented by an optional interface on the classification tree, and each node of the classification tree can then instantiate the relevant interfaces. For example, some nodes may be valid for assets and others for assets, models, and variants. The relevant class definitions for each member of the family are related to the node of the tree, and this relationship is inherited down the tree.

When a family uses the same class definition on all nodes of the tree, then this relationship only needs to be created at the top node, and the tree can be described as a Homogeneous tree as is the case for the Design Document. When the family uses different class definitions at different nodes of the tree, it can be described as Heterogeneous, which is the case for equipment with different class definitions for pumps, vessels, and so forth.

Attached to the optional interfaces are various methods to create and query the relevant family of objects. The methods reference the relationship path to the class definition used when the object is created. The number of alternative class definitions that can be created from one classification is therefore limitless.

For example, in the case of a catalog classification tree used to create both Model, Variant, and Tag business items, there would be optional interfaces on the classification class definition for each family with create and query methods attached. Optional interfaces are used because it is not always valid to create all families from all nodes of a classification tree.

A business item can be classified by two different trees. For example, a primary tree could be configured for the organization and separate classification trees for their vendors and sub-contractors. When a business item is created within the structure of one classification tree, it is automatically related to the alternative trees.

Use the SmartPlant Foundation Schema Editor to model classification trees. See SmartPlant Schema Editor Overview for more information.

See Also

Configure a new classification tree
Classification tree example use case