Model Business Logic concepts

While the AVEVA Unified Engineering Default Configuration is recommended as a starting point, it can be extended for project workflows and client requirements. AVEVA discourages using a Custom Data Model, as starting with the Default Configuration ensures compatibility with business logic and object-specific code through its upper ontology inheritance.

The behavior is imparted on the object by tagging it or decorating it with the required behavioral vocabulary item. Therefore, you can customize and extend these models by decorating an attribute, class or association with a vocabulary item. The class, attribute, or association takes on the necessary business logic behavior.

The physical characteristics and behavior needed by the business logic is attached not only to the item, but is inherited down the tree.

Intelligence built-in

The most powerful concept is getting the business logic to react to the relationships between classes, rather than to the classes themselves or the associations. This means that any model can be extended while still behaving intelligently.

Behaviors, and therefore business logic, is implicit to the base associations and not the classes. The behavior is achieved no matter what is at either end of the association. Once instantiated, you can traverse associations to reach other classes and associations in any direction as the inverse is also generated.

There are four base associations:

• References

• Has Part

• Can Have Part

  This base association has a part. However, this base association defers part creation to on demand.

• Is realized by

  This base association handles lifecycle concept changes or expansions.

References are associations relating objects to other objects. This linking can be decoupled without affecting any of the three objects. Any one object can be deleted without affecting the others.

For example:

• The pipe has two reference associations to the to and from object (Valve to the to object, the pump to the from object).

• If a part defined as Has Part is needed, deliverables such as datasheets have sections for the parts. The hierarchy groups physically similar objects.

Common parts are defined just once and are associated to the group that is higher up in the hierarchy. Common parts can be inherited.

Unlike References, parts must have a parent. If the parent is deleted, so are its parts. With Has Part on the parent creation, the logic creates the part and links it to the parent.

At the early stage, a pumping operation is deemed a suitable, theoretical simulation that turns into the pumping requirement needed to fulfill the operation on a Process Flow Diagram (PFD). The requirement is made physical or is realized by maybe two duty and one standby pumps on the Piping and Instrumentation Diagram (P&ID).

With regards to functional and physical in the doing (authoring tool), we use the following definition as it allows us to specialize from functional to physical. We also maintain a relationship for any expansion. For example, the functional item is realized by a specialization of the functional item (the physical item). We also have the requirements item (Simulation items).

Definition example

The definition of PUMP is decorated as a Functional Object that has a capability of PUMPING. If accompanied by all the necessary parts and subsystems, it can refer to a PUMP SYSTEM.

By inheritance, a CENTRIFUGAL PUMP and all its subclasses and sub-subclasses have the capability of pumping.

The few attributes of PUMP are inherited by CENTRIFUGAL PUMP and the attributes of CENTRIFUGAL PUMP are again inherited by the shown AXIAL FLOW PUMP and RADIAL FLOW PUMP (and other subclasses). All subclasses have the capability of pumping.

We can now define a further specialization of PUMP, such as PUMP with particular QH curve, and make the statement that the specialization applies to my AXIAL FLOW PUMP class, as defined on its technical specification: