Connect Engineering to Name allocation manager

Name allocation manager seamless integrates with AVEVA Unified Engineering.

To apply the NAM settings or create type mappings in Engineering config module, you must be in Config administrator role in NAM.

Note:
An Engineering project can only be linked to a scope. Therefore,it is recommended that you do not assign a scope to a referenced project. For example, MLP should not be connected to a scope, as every project that references it would inherit the same scope.

Here are the business rules:

Engineering only supports Primary sequence for a naming rule, it does not support a Secondary sequence.

It is not feasible to retain the counter, if no part of the tag contributes to uniqueness during renaming. In those cases, the system assigns the next available counter.

For the Preserve name option to function correctly, a naming rule must be defined for the top-level class. This rule should contain a single name part and be placed within a Name context mapped to the NAME attribute. Such a naming rule is required because only business logic executed during compare update can support the Preserve-name option.

Type mappings are resolved based on the class URI defined in the Conceptual model, under the assumption that each Conceptual model provides unique URIs. For example, if the MLP project is referenced by multiple projects, their data models remain identical. However, users may sometimes export a data model from one project into another, creating a clone. Although this cloned model can be modified independently, it still retains the original unique identifiers for the imported classes. As a result, type mappings may appear to work but can produce inconsistencies because the clone is not the same referenced MLP project. Therefore, when working with such variant projects, it is recommended you define a new set of naming rules.

When the Prevent duplicate names option is enabled for a name context, no naming rule will generate duplicate names. In earlier versions of Engineering, unique names were generated only for naming rules that wrote to the NAME attribute or for rules that included a sequence.This ensures consistent and predictable sequence allocation across all naming rules within a Name context, as long as the required preconditions for the FIRST and NEXT sequence options are satisfied.

Preconditions for Name Generation

A name will be generated only if all the following conditions are satisfied:

• Minimum length validation.

• Maximum length validation. For example,when a maximum length is defined for a sequence, the system ensures that generated values do not exceed this limit. For example, if the maximum length is set to 3, the sequence cannot go beyond 999. Once the value 999 has been assigned, any further attempt to allocate a new value using the NEXT option will fail validation, as no additional sequence numbers can be generated within the allowed range.

• •Sequence reservation criteria validation

• •When all preconditions are met, name allocation with both First and Next option will succeed.

When a naming rule does not include a sequence, and no values are provided for the configured name parts in the Engineering client, no name allocation request is sent to NAM. Therefore, the tag is created without a generated name. If a name is required, you must rename the tag by providing the name part values.

When a type mapping is deleted for a class, it is removed across all Scope + Name context combinations that use the naming rule associated with that type. This occurs because the same naming rules and their type mappings are referenced across all scopes and name contexts.

If a Name context is deleted in Name allocation manager but is still mapped to a writable attribute in the Engineering configuration, it will not be fully removed from the project automatically. To complete the removal, select Name Context Mapping in Engineering configuration and select Save to update the configuration.This removes the Name context from the project.

Connecting Additional Scopes in a Solution

When adding a second or subsequent scope to a solution, keep the following considerations:

Type Mapping Reuse

Type mappings are linked to naming rules stored in the shared library. As a result, any type mappings defined for the first scope that uses the same data model are automatically applied to all subsequent scopes that rely on the same naming rules. This eliminates the need for redundant type mapping configuration in later projects.

Automatic Type Mapping Import

When a project is connected to a second scope, the system automatically imports the type mappings that were defined for the first scope. However, these imported mappings are only active when the user opens the Type Mapping dialog within the project.

Name Context Mapping Requirement

Name contexts are scope-specific, therefore each scope must have its Name contexts mapped to a write attribute. The Type Mapping dialog becomes accessible only after all Name contexts within the scope have been mapped.

Database Selection

When you open the Name Context dialog, the system prompts you to select the Engineering database where the Name Context mappings should be stored.

Shared Type Mappings

Type mappings are shared across all scopes. If you modify them in one project it will automatically update them in other projects. An alternative approach is to create cloned naming rules to isolate type mappings for specific projects.

To set up tags management in Engineering Configuration, refer to Tags Management Setup and Configuration.

Connect Engineering to Name allocation manager enables the integration of Name allocation manager with AVEVA engineering.

On the Project tab, in the Settings group, select Name allocation manager. Click Connect Folder to display a drop-down list of available options. Select a folder, for example Nas Dev.

Click Scope to display a drop-down list of available options. Select a scope. For example, PIDScope.A message is displayed indicating that the project is successfully linked to Name allocation manager

A change to a new scope generates a warning message.A new scope gets set with the change.