Understand the AVEVA Class Library

This section outlines the following areas to help you understand the AVEVA Class Library:

• Model types

• AVEVA Unified Engineering Default Configuration Class and Attribute model

• Model independent of application

  Note: The AVEVA Unified Engineering Default Configuration Class and Attribute model is independent of AVEVA Information Standards Manager (ISM).

Model Types

The following model types are used in the AVEVA Unified Engineering Default Configuration Governance:

• Tool Centric Models

• Asset Centric Models

Tool Centric Models tend to be siloed with domain views. Each model is seen as the hub of the design, independent in terminology, and shows how they are categorized.

• Every discipline sees the data through their deliverable's lens. This context gives rise to differing main perspectives and loaded terminology.

• This model requires mapping across disciplines. The mapping needs analysis and manual interpretation to understand the intent. Finding equivalents is difficult as the structures, level of detail, and naming varies.

  

Asset Centric Models, unlike tool centric models, tend to be holistic with domain views. Treat the domain data in a holistic, asset centric way. If you build your discipline views and deliverables from this method, then the system naturally integrates as it becomes holistic and represents all of the disciplines.

We can mimic the appearance of a plant, but it is a fictitious representation and cannot parametrically move as a plant does. For the digital twin to react as a plant would, it needs the components to interact and move parametrically as the components move and interact in a real plant.

A collection of independent classes does not give the connectivity required for a digital twin. Structure, order, and connectivity is required for an interaction to occur. The points of inflection that drive the parametrization, the parts, must be present. We can then drive the parameters in directions that we didn't envision when we started. In other words, it's not a static statue.

The one common perspective is not tied to any specific domain view, but rather the physical asset view, as it is common to all disciplines.

A common physical perspective helps federate domains and is the common data dictionary that everyone can understand. This perspective spans design and operations. It is hard to evolve the design across disciplines without a common basis. By having a common physical perspective, the true digital twin can evolve as the physical design evolves. Rather than re-entering or mapping constantly, the individual aspects data is enriched.

Segregating and federating the submodels gives the ability to add new domains or extend existing ones.

The digital twin can only be a reality when you lower its bar to maintain it, where it then can remain evergreen. Lowering the bar requires the digital twin to have the capability to grow easily, building on design data not re-entering stripped out data. The data built up in the design can then be re-purposed in monitoring, Asset Performance Management (APM), and Industrial Internet of Things (IIOT).