Custom class library update

For customers using a proprietary or custom class library who want to incorporate the AVEVA Master Project (MLP) class library, it is important to assess the structural differences in the class model across the following areas.

Important: An experienced administrator who understands both the existing class model and the existing project-specific modifications should perform this operation. This helps prevent data loss and avoids overwriting changes currently in use by the project.

The administrator must maintain a proper change log of all updates made to the existing model. Use the change log to review the Preview Import results and to determine whether to accept or reject updates from the newer version of the class model.

Before performing any class model delta update, we highly recommend that you back up the project.

Differences in class model taxonomy (hierarchy and classification structure)

Assess how the class library organizes and classifies information, which might include:

• Differences in top-level domains and grouping principles (for example, by discipline, function, or equipment type).

• Differences in granularity (the MLP may define more specialized classes or the customer model may be more detailed in certain areas).

• Differences in parent-child hierarchy (a class may exist in both libraries but reside under different parent classes).

• The need to determine whether mappings should be:

  • One-to-one.

  • Many-to-one for consolidation.

  • One-to-many for splitting into multiple MLP classes.

Differences in class model ontology (semantics and relationships)

Assess how the model defines entities and represents relationships between them, including:

• Differences in relationship types (such as havepart, hasPart, connected to, or Reference).

• Differences in relationship implementation (such as association names, directions, and cardinality rules).

• Differences in modeling approach (for example, the MLP may apply a more componentized structure by separating devices such as sensor elements, transmitters, converters, panels).

• The need to evaluate not only the class name, but also whether the expected relationships exist to support typical engineering use cases (such as tagging and loop definitions).

• Not only class equivalency, but also whether the expected relationships exist to support common engineering use cases such as tagging, loop definitions, and asset associations.

Differences in class definitions and naming conventions

Assess how the model defines classes and applies naming standards, including:

• The use of the same term to represent different concepts.

• Differences in definition scope (what each definition includes or excludes).

• Variations in naming standards (such as abbreviations and discipline prefixes).

• The need to align synonyms and confirm whether a class is a true equivalent match or only a contextual match.

Differences in class attributes (properties, constraints, and data model rules)

Assess the data each class stores and the rules governing that data, including:

• Different attribute sets per class (the MLP may require attributes that do not exist in the custom class library).

• Attribute differences in:

  • Attribute Name

  • Domains

  • Data types

  • Units of measure

  • Valid Values

  • Hold multiple Case Value

  • Other class-specific differences

Update a custom class library

Use the preceding lists to assess the structural differences between the customer class model and the AVEVA Master Library Project (MLP), and perform the following steps.

1. Analyze both class models.

   Perform a structured comparison between the customer’s proprietary/custom class library and the AVEVA Master Library Project (MLP) class library:

   1. First-level class model comparison:

      Compare the customer class model against the MLP class model to identify gaps (high-level alignment and coverage).

   2. Second-level comparison:

      Analyze and compare the ontological and hierarchical structure and relationships (for example, parent/child placement, associations, and semantic meaning) between the customer model and the MLP class model.

   Note: AVEVA Engineering includes a Model Analysis capability within the Preview Import functionality to support first-level model comparisons. Use the tool to compare models using exact name matches, URLs, or identity reference numbers. With this tool, you can efficiently identify differences between the customer class model and the MLP class model.

   Refer to Preview Import File in the AVEVA Engineering documentation for more information.

2. Identify and document gaps.

   Use the comparison results to identify and document gaps. This may include missing classes, misaligned hierarchy, missing relationships, attribute differences, and naming or definition mismatches.

3. Update the AVEVA MLP class model.

   Ensure accordance with established MLP governance processes (see Governance — update, maintain, and enhance for more information). Use the gap analysis and comparison report to guide which changes should be implemented.

   Important: Before you continue, verify that the minimum update requirements have been satisfied. See Adopt class library changes for more information.

4. Build the class model.

   This instantiates the updates and applies the changes to the database.