Lexicon Rev 1.0

Lexicon

TM-1308

TRAINING GUIDE

AVEVA Plant (12.1)

www.aveva.com

AVEVA Plant (12.1) Lexicon TM-1308

www.aveva.com © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

2


Revision Log Date

Revision

Description of Revision

Author

Reviewe d

11/01/2012 20/01/2012

0.1 0.2

Issued for Review PDMS 12.1.SP2 Issued for Review

KB / IRS KB/IRS

IRS/SB

26/03/2012

1.0

Approved for Training PDMS 12.1.SP2

KB/IRS

IRS/SB

Approved

NG

Updates All headings containing updated or new material will be highlighted.

Suggestion / Problems If you have a suggestion about this manual or the system to which it refers please report it to AVEVA Training & Product Support at [email protected] This manual provides documentation relating to products to which you may not have access or which may not be licensed to you. For further information on which products are licensed to you please refer to your licence conditions. Visit our website at http://www.aveva.com

Disclaimer 1.1

AVEVA does not warrant that the use of the AVEVA software will be uninterrupted, error-free or free from viruses.

1.2

AVEVA shall not be liable for: loss of profits; loss of business; depletion of goodwill and/or similar losses; loss of anticipated savings; loss of goods; loss of contract; loss of use; loss or corruption of data or information; any special, indirect, consequential or pure economic loss, costs, damages, charges or expenses which may be suffered by the user, including any loss suffered by the user resulting from the inaccuracy or invalidity of any data created by the AVEVA software, irrespective of whether such losses are suffered directly or indirectly, or arise in contract, tort (including negligence) or otherwise.

1.3

AVEVA's total liability in contract, tort (including negligence), or otherwise, arising in connection with the performance of the AVEVA software shall be limited to 100% of the licence fees paid in the year in which the user's claim is brought.

1.4

Clauses 1.1 to 1.3 shall apply to the fullest extent permissible at law.

1.5

In the event of any conflict between the above clauses and the analogous clauses in the software licence under which the AVEVA software was purchased, the clauses in the software licence shall take precedence.


3


Copyright Copyright and all other intellectual property rights in this manual and the associated software, and every part of it (including source code, object code, any data contained in it, the manual and any other documentation supplied with it) belongs to, or is validly licensed by, AVEVA Solutions Limited or its subsidiaries. All rights are reserved to AVEVA Solutions Limited and its subsidiaries. The information contained in this document is commercially sensitive, and shall not be copied, reproduced, stored in a retrieval system, or transmitted without the prior written permission of AVEVA Solutions Limited. Where such permission is granted, it expressly requires that this copyright notice, and the above disclaimer, is prominently displayed at the beginning of every copy that is made. The manual and associated documentation may not be adapted, reproduced, or copied, in any material or electronic form, without the prior written permission of AVEVA Solutions Limited. The user may not reverse engineer, decompile, copy, or adapt the software. Neither the whole, nor part of the software described in this publication may be incorporated into any third-party software, product, machine, or system without the prior written permission of AVEVA Solutions Limited, save as permitted by law. Any such unauthorised action is strictly prohibited, and may give rise to civil liabilities and criminal prosecution. The AVEVA software described in this guide is to be installed and operated strictly in accordance with the terms and conditions of the respective software licences, and in accordance with the relevant User Documentation. Unauthorised or unlicensed use of the software is strictly prohibited. Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved. AVEVA shall not be liable for any breach or infringement of a third party's intellectual property rights where such breach results from a user's modification of the AVEVA software or associated documentation. AVEVA Solutions Limited, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom

Trademark AVEVA and Tribon are registered trademarks of AVEVA Solutions Limited or its subsidiaries. Unauthorised use of the AVEVA or Tribon trademarks is strictly forbidden. AVEVA product/software names are trademarks or registered trademarks of AVEVA Solutions Limited or its subsidiaries, registered in the UK, Europe and other countries (worldwide). The copyright, trademark rights, or other intellectual property rights in any other product or software, its name or logo belongs to its respective owner.


4

Contents 1

Introduction .............................................................................................................................................. 7 1.1 Aim..................................................................................................................................................... 7 1.2 Objectives ......................................................................................................................................... 7 1.3 Prerequisites .................................................................................................................................... 7 1.4 Course Structure .............................................................................................................................. 7 1.5 Using this guide ............................................................................................................................... 7 1.6 Setting up the Training Course ...................................................................................................... 8 2 Overview of the Lexicon Module ............................................................................................................ 9 2.1 Data Hierarchy and Element Types ................................................................................................ 9 2.2 User Defined Attributes ................................................................................................................. 10 2.2.1 User System Defined Attributes ............................................................................................... 10 2.2.2 User Defined Element Types ................................................................................................... 10 2.2.3 Status Definitions and Values .................................................................................................. 10 2.2.4 Database Views ....................................................................................................................... 10 2.3 Features of the Lexicon User Interface ....................................................................................... 11 2.4 The Lexicon Menu .......................................................................................................................... 11 2.5 The Utilities Menu .......................................................................................................................... 12 2.6 The Display Menu........................................................................................................................... 12 2.6.1 The Dictionary Explorer ............................................................................................................ 12 2.6.2 Current Element Editor ............................................................................................................. 13 2.6.3 Database Views Editor ............................................................................................................. 14 2.6.4 Graphical View ......................................................................................................................... 14 2.6.5 Search and Search Results ..................................................................................................... 15 2.6.6 Command Window ................................................................................................................... 15 2.7 The Edit Menu................................................................................................................................. 15 2.8 The Create Menu ............................................................................................................................ 16 2.9 The Modify Menu ............................................................................................................................ 16 2.10 The Help Menu................................................................................................................................ 16 2.11 Schematic Model Manager ............................................................................................................ 16 Exercise 1 Entry to PDMS ........................................................................................................................ 16 3 User Defined Attributes ......................................................................................................................... 17 3.1 UDA Hierarchy ................................................................................................................................ 17 3.2 UDA Fields (Current Element Editor) ........................................................................................... 18 3.2.1 General ..................................................................................................................................... 18 3.2.2 Basic Definition......................................................................................................................... 18 3.2.3 Presentation ............................................................................................................................. 21 3.2.4 Protection ................................................................................................................................. 21 3.2.5 Design ...................................................................................................................................... 22 3.2.6 Miscellaneous ........................................................................................................................... 22 3.3 Creating User Defined Attributes – A Worked Example ............................................................ 23 3.3.1 Creating a UDA World (UWRL) ................................................................................................ 23 3.3.2 Creating a UDA Group (UGRO) ............................................................................................... 23 3.3.3 Creating a User Defined Attribute ............................................................................................ 24 Exercise 2 Creating and Using UDA’s .................................................................................................... 26 4 User System Defined Attributes ........................................................................................................... 27 4.1 USDA Hierarchy ............................................................................................................................. 27 4.2 USDA Definition ............................................................................................................................. 27 4.2.1 USDA Limits and Valid Values ................................................................................................. 28 4.3 Creating a USDA – A Worked Example ....................................................................................... 28 Exercise 3 Creating and Using USDA’s .................................................................................................. 32 5 User Defined Element Type .................................................................................................................. 33 5.1 UDET Hierarchy .............................................................................................................................. 33 5.2 UDET Definition .............................................................................................................................. 33 5.2.1 General ..................................................................................................................................... 33 5.2.2 Basic Definition......................................................................................................................... 34 5.2.3 UDET Hierarchy ....................................................................................................................... 34 5.3 Creating a User Defined Element Type (UDET) – A Worked Example ...................................... 35 www.aveva.com 5.3.1 Creating a UDET Element World (UDETWL) .......................................................................... 35 5


5.3.2 Creating a UDET Group (UDETGR) ........................................................................................ 35 5.3.3 Creating a User Defined Element Type (UDET) ...................................................................... 36 Exercise 4 Creating and Using UDET’s .................................................................................................. 38 6 Status Control ........................................................................................................................................ 39 6.1 Overview ......................................................................................................................................... 39 6.2 The Status Control Data Model ..................................................................................................... 39 6.3 Hierarchy Overview........................................................................................................................ 40 6.4 Status Control Hierarchy - Lexicon .............................................................................................. 40 6.5 Status Control Hierarchy – Constructor Modules ...................................................................... 41 6.6 Implementing Status Control – A Worked Example ................................................................... 41 6.6.1 Creating Status Worlds ............................................................................................................ 42 6.6.2 Creating Status Groups ............................................................................................................ 42 6.6.3 Creating Status Definitions ....................................................................................................... 43 6.6.4 Create Status Values ............................................................................................................... 44 6.6.5 Testing Status Control in Design .............................................................................................. 47 Exercise 5 – Creating Status Values ............................................................................................................ 49 6.7 Status Control Customisation ...................................................................................................... 50 6.8 Data Access Control ...................................................................................................................... 50 6.8.1 Prevent Modification of an Object of a Certain Status ............................................................. 50 6.8.2 Prevent Promotion of an Object by Certain Users ................................................................... 50 6.9 Auto Colours .................................................................................................................................. 51 6.9.1 Equipment with Design Status Not Controlled ......................................................................... 51 6.9.2 Equipment with Design Complete ............................................................................................ 51 6.10 PML Customisation........................................................................................................................ 51 6.11 .Net Customisation (C#) ................................................................................................................ 51 6.12 Status Control Customisation – A Worked Example ................................................................. 52 7 Database Views ...................................................................................................................................... 55 7.1 Overview ......................................................................................................................................... 55 7.2 Database View World (DBVWWL) Hierarchy ............................................................................... 56 7.2.1 Creating Database View Administrative Elements ................................................................... 56 7.3 Database View (DBVW) Hierarchy ................................................................................................ 57 7.3.1 Creating Database View .......................................................................................................... 58 7.3.2 Creating a Database Views Elements ..................................................................................... 60 7.4 Database Views Editor .................................................................................................................. 63 7.4.1 Displaying the Database Views Editor ..................................................................................... 64 7.4.2 View Properties tab .................................................................................................................. 68 7.4.3 Data Sources tab...................................................................................................................... 69 7.4.4 Columns tab ............................................................................................................................. 69 7.4.5 Preview tab ............................................................................................................................... 71 7.5 Creating a Branch and Pipe Database View – A Worked Example ........................................... 72 7.5.1 Creating the DBVW .................................................................................................................. 72 7.5.2 Defining the Data Sources ....................................................................................................... 74 7.5.3 Defining the ATTCOL and EXPCOL columns .......................................................................... 75 7.5.4 Testing the Database View ...................................................................................................... 78 Exercise 6 – Creating a Nozzle Database View .......................................................................................... 79 7.6 Modifying the Branch and Pipe DBVW using SRCELE – A Worked Example ......................... 80 7.6.1 Copying a Database View ........................................................................................................ 81 7.6.2 Testing the Database View ...................................................................................................... 85 Exercise 7 – Modifying the Nozzle Database View ..................................................................................... 87 7.7 Using Database Views for Lexicon Administration – A Worked Example ............................... 88 Exercise 8 – Create a DBVW that checks for UNSET Descriptions .......................................................... 91


6

CHAPTER 1

1

Introduction

The AVEVA Plant (12.1) Lexicon training guide is designed as a continuation to the AVEVA Plant (12.1) System Administration Basic and Advanced training guides. The LEXICON Module allows the system administrator complete control of the administration of the Dictionary (DICT) databases of a project.

1.1

Aim

To understand the use of Lexicon on a PDMS Project using practical worked examples and exercises.

1.2

Objectives

Through the completion of the training, the Trainee will have sufficient knowledge to complete the following tasks: 

Create and use User Defined Attributes (UDA’s), User System Defined Attributes (USDA’s), and User Defined Element Types (UDET’s). Outline the principles of Status Control and its administrative hierarchy. Create, modify and implement Status Definitions and Values. Consider simple examples of automated Status Control events. Create, modify and implement Database Views.

   

1.3

Prerequisites

It is expected that trainees will have completed the following training courses: TM-1300 AVEVA Plant (12.1) System Administration (Basic) and TM-1301 AVEVA Plant (12.1) System Administration (Advanced). Trainees who have not completed these courses, but can demonstrate a working knowledge of PDMS Administration, may be permitted to undertake the course at the Trainers discretion.

1.4

Course Structure

Training will consist of oral and visual presentations, demonstrations and set exercises. Each workstation will have a training project, populated with model objects. This will be used by the trainees to practice their methods, and complete the set exercises.

1.5

Using this guide

Certain text styles are used to indicate special situations throughout this document:  

Menu pull downs and button press actions are indicated by bold dark turquoise text. Information the user has to key-in indicated by bold red text.

Supplementary information or guidance notes will be distinguished by a turquoise information symbol and accompanying text:



Additional information References to other training guides/sections and documents will be distinguished by a book symbol and accompanying text:  Refer to other documentation

© Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

www.aveva.com 7


System prompts will be displayed in inverted commas using italicised bold text e.g. 'Choose function'. Example files or inputs will be in the courier new font, utilising colours and styles outlined above where appropriate.

1.6

Setting up the Training Course

As Lexicon is an Administrative module, access is restricted to free users only. Login to PDMS using the details provided by the Trainer. They will typically be as shown below:

Project

Training

Username

-

SYSTEM

Password

-

XXXXXX

MDB

-

A-PIPING

Click the Login button.

Select Utilities > Training Setup… from the main menu to display the Training Setup form. Navigate to the Lexicon tab.

Check the Setup Training Course checkbox, click the Apply button and close the form.


8

CHAPTER 2

2

Overview of the Lexicon Module

The Lexicon Module allows the system administrator to create and manage a number of user defined attributes and element types. System attributes can also be managed allowing administrators to set valid values and limits. The Lexicon module allows the creation and management of status workflows, via user defined status values and status change events. Database views can also be constructed within Lexicon, enhancing project reporting methods and allowing for the use of distributed attributes in projects.

2.1

Data Hierarchy and Element Types

Elements created in Lexicon are stored in Dictionary (DICT) databases. To make elements created in Lexicon appear in a project, the DICT database must be included in a project Multiple Database (MDB) using the Admin module. As with other PDMS modules, Lexicon elements are owned by other elements and must adhere to a specific data hierarchy. Some minor variations exist in the Lexicon hierarchy; however the general hierarchy is of the form shown. An Explorer is available within Lexicon and the hierarchy for a specific element can be viewed within it. Dictionary World

Element World

Element Group

Element

All elements created in Lexicon are owned by the top level element, the Dictionary World. Beneath the Dictionary World a number of element specific Worlds can be created. In turn, the element worlds may own element Groups. Worlds and Groups are administrative elements, providing a means of organising Lexicon elements to meet project requirements. A range of elements can be created within Lexicon including: 

User Defined Attributes.



User System Defined Attributes.



User Defined Element Types.



Status Definitions and Values.



Database Views.


www.aveva.com 9


Hierarchy details specific to each element will be considered later in the training guide. A brief description of each element type is provided in the sections that follow.

2.2

User Defined Attributes

A User Defined Attribute (UDA) enables the administrator to add new attributes to any element in the databases of a project. A UDA can be used to add engineering data to elements for example “Designed”, “Checked”, etc. UDAs are created as elements in Dictionary databases inside a project. Because LEXICON databases are project specific, it is possible to define attributes to suit individual project requirements. Once defined, UDAs may be accessed in much the same way as normal attributes, including setting values, querying and reporting upon these values. Utilities such as the Data Output and Project Reconfiguration functions treat UDAs as they would any other attributes. UDAs can also be used in expressions.

2.2.1

User System Defined Attributes

A User System Defined Attribute (USDA) allows the administrator to place behaviour on a standard PDMS element. For example, limits may be applied to the attributes of top level elements within PDMS. A USDA allows the administrator to add the following behaviour to system attributes:

2.2.2



Set valid values.



Define limits.



Hide attributes on forms.



Category.

User Defined Element Types

Within PDMS the standard set of elements are often used for a variety of purposes. A User Defined Element Type (UDET) allows an element to be created with a more meaningful name. UDETs allow Designers to create real engineering items e.g. “Pumps”, “Towers” or Areas. UDETs are based on existing PDMS Item Types.

2.2.3

Status Definitions and Values

Status Control provides administrators with a means to control and report on the status of individual model objects as they progress through their lifecycles. Status control can be applied to any PDMS element used in the constructor modules e.g. Design, Paragon, Spooler, Diagrams, Draft, Tags. The desired project workflow is created by the administrator as a Status Definition, or number of Status Definitions, in the Lexicon module. Status Definitions own Status Values, which describe the stage of development for the PDMS element concerned.

2.2.4

Database Views

Database views provide a way to consolidate data from elements and attributes distributed across databases in an MDB. These views are set up by an administrator using the Database Views Editor and stored in the Lexicon (DICT) database in a Database View World (DBVWWL). User database views may also be saved in a local settings file. As well as the user definable views, each PDMS element type has its own Element View. A Database View uses a table to define a view of the data, which may be derived from a single or multiple elements. There is a row in the Database View table for each element of a particular type that meets the www.aveva.com criteria defined by filters. These filters use the same concept as the search grid. If the criteria cannot be © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

10


expressed using attribute filters, it is also possible to define an expression for evaluation. A row is present in the table only if all the filter criteria are met. Database Views provide method to derive data structures for a variety of purposes, in particular List definitions in the Engineering Tags module, as well as for the Report Designer.

2.3

Features of the Lexicon User Interface

The Lexicon Module has a similar User Interface (UI) to other PDMS modules. When the UI is first accessed the left hand side of the UI is populated with the Dictionary Explorer and Current Element Editor. The Search toolbar is also displayed beneath the main menus.

Space to the right hand side of the UI is gradually populated as other options, such as displaying Graphical Views and Search Results, are selected from the Lexicon menus. A number of functions are available from the main menu. An overview of the menu options is provided in the sections that follow.

2.4

The Lexicon Menu

The Lexicon menu options available include getting and saving database changes, switching to other modules, and exiting the application.


11


2.5

The Utilities Menu

The Utilities menu is normally only available if the AVEVA Training Setup has been loaded. It is used by AVEVA Trainers to aid the Training Process.

2.6

The Display Menu

The Display menu allows users to select the forms that will be displayed in the UI. The options available under the Display menu are outlined below.

2.6.1

The Dictionary Explorer

The Display > Dictionary Explorer option is used to display or hide the Dictionary Explorer.

A list of elements held in the Lexicon Database is populated in the Dictionary Explorer. Any element can be selected, copied, or deleted, by clicking the right mouse button on the element.

Options displayed when using the right click menus are context sensitive. The options displayed will vary depending on the element selected. For example, if the Current Element (CE) is the Dictionary World:


12


Examples of other menu options are shown below.

Example of the options when the CE is a UWRL (UDA World).

2.6.2

Example of the options when the CE is a UGRO (UDA Group).

Current Element Editor

The Display > Current Element Editor option prompts the Current Element Editor form. This form is used to edit the CE and dynamically tracks the Dictionary Explorer. The displayed information changes depending of the type of element selected.

Example of a UWRL.

Example of a UDA.


13


2.6.3

Database Views Editor

The Display > Database Views Editor option displays the Database View Editor which, as the name suggests, is used to create views on the PDMS database. This option is discussed in full later in this guide.

2.6.4

Graphical View

The Display > Graphical View option displays the Graphical View which, in turn may be populated by a right-click menu option within the Dictionary Explorer.

This example shows a Status Definition workflow.

The example below shows User Defined Element Types based on Equipment.


14


2.6.5

Search and Search Results

The Display > Search… and Display > Search Results… options are common across a number of PDMS modules, allowing the searching, display and editing of data.

2.6.6

Command Window

The Display > Command Window… option allows use of the Command Window in Lexicon.

2.7

The Edit Menu

The options under the Edit menu, with the exception of Validate, are commonly used PDMS functions and should be self-explanatory. Validate is used to check the Lexicon Database for errors which must be corrected prior to using the Lexicon data.


15


2.8

The Create Menu

The Create menu can be used to create Lexicon Elements. It is context sensitive depending on the CE selected in the PDMS Hierarchy. This is illustrated in the examples below.

These options are available at World Level.

The creation of a UDA and USDA are only available when at UGRO Level.

2.9

The Modify Menu The Modify menu lists a number of options relating to the Lock attribute of Lexicon elements.



Subject to the type of element selected, some of the options may not be available.

2.10 The Help Menu

The Help menu displays a range of standard PDMS help options available to the user.

2.11 Schematic Model Manager Schematic Model Manager is an optional module. For further information refer to Schematic Model Manager User Guide.

Exercise 1

Entry to PDMS

Enter the PDMS Training Project as described and explore the Lexicon menu options.


16

CHAPTER 3

3

User Defined Attributes

User Defined Attributes enable the PDMS system administrator to add new attributes to any element in the databases of a project. UDAs can contain Limits e.g. Temperature 1 – 200, or have Valid Values e.g. AREA01, AREA02, etc. applied to them.

3.1

UDA Hierarchy

In order to create a User Definable Attribute (UDA) the user must first navigate to the correct place in the Lexicon hierarchy. A UDA can only be created from a UDA World (UWRL) or UDA Group (UGRO).

With the Dictionary World selected as the CE, the user can create a new UDA World using either the main Create menu or via the right click context menu in the Dictionary Explorer.

A UDA Group and a UDA are created in a similar way.


17


3.2

UDA Fields (Current Element Editor)

Once the UDA is created, the Current Element Editor form displays a number of fields associated with the UDA. The fields are grouped into a number of categories. The fields relevant to each category are considered in the sections that follow.

3.2.1

General

Fields grouped into the General category include some system generated values that cannot be directly changed by the user (e.g. Owner). These fields appear in a lighter colour than fields that can be edited directly.

Fields that can be edited directly include:

3.2.2



Name The user can enter a valid name for the UDA in the Lexicon database. Special characters are not allowed. Although the system will accept numeric values it is good practise to avoid using them.



Lock This field determines whether or not the fields defining a UDA are locked. The field can be set to True (locked) or False.



Description A brief description of the UDA can be provided to assist users.

Basic Definition

Several fields relating to the Basic Definition category are dynamic. The selections made in one field dictate the values and other fields displayed in the Current Element form.


18




Abbreviation Length This field defines the minimum number of characters that the attribute name can be shortened to for use in commands and attribute entry fields. For example, if the UDA Name is DIAGRAM, and the Abbreviation Length is 5, the user must type 5 characters to define the UDA (e.g. DIAGR). The abbreviation name must be less than or equal to the number of characters used in the User Defined Name and must be unique in its own right.



UDA Type Subject to the type chosen, other relevant fields will be displayed accordingly. This is demonstrated in the examples that follow. Consider first a UDA Type set to logical.

The UDA Default value can then only be set as either ‘True’ or ‘False’.

If the user selects the UDA Type of reference, then the Referred types field is displayed (and the UDA Default field is not).

The Referred types field can be populated from the Select Element Types form. This form allows users to select the required elements from a pre-populated list.


19


A filter is available to assist users in making an appropriate selection.

If the UDA Type is set to real the UDA Units can be set.



Element Type This is the PDMS element that the UDA will be applied too e.g. Pipe, Equipment, Drawing, etc.

As with Referred elements, there is a filter option to help users select the required Element Types.


20




Pseudo Attribute Setting this logical attribute to True will indicate the UDA is pseudo attribute. Pseudo attributes allow for dynamic values to be returned as needed, rather than having static values stored in the database. The code required to return a pseudo attribute value must be plugged in through the use of the C# API and is out of the scope of this guide.



Indexed UDA The indexing of UDA’s is controlled by the UTABLE attribute on the UDA definition in the dictionary DB. If this is set to True then the UDA will be indexed. Indexing is allowed for text, reference and integer UDAs only.



User Defined Name This allows the user to enter a name that will be given to the UDA of the element it will be created for. It should be set to a similar name as the UDA. Special characters are not allowed for UDA names. Although the system will accept numeric values it is good practise to avoid using them.

3.2.3

Presentation

The fields within the Presentation category remain the same irrespective of the type of UDA created. A brief description of each field is provided below.



Reporter text A text attribute used to define the default column heading used in reports. This field can be up to 20 characters in length.



UDA Category This can be used to Group UDAs together within the Modify Attributes form.



Hidden If this field is set to True the data will be hidden from the user.



Hyperlink If this field is set to True the text value of a UDA will be allowed to contain a path to an external file.



Connection If this field is set to True it indicates that the UDA is a connection in the reference list.

3.2.4

Protection

The Protection category only contains one field relating to the UDA.



Protected If this field is set to True, and the UDA is to be stored in a protected database, it will not be viewed.


21


3.2.5

Design

The Design category only contains one field relating to the UDA.



Valid Values Depending on the type of UDA created, numeric values, a range of values, or text strings can be set in this field. Items must be separated by a suitable delimiter specific to the type of value being entered.

To assist this process, the Edit Valid Values form can be opened from the valid value entry cell.

3.2.6

Miscellaneous

The Miscellaneous category only contains one field relating to the UDA.



Limits or Valid Values Optional Flag If this field is set to True the limits or valid values set in the form are optional.


22


3.3

Creating User Defined Attributes – A Worked Example

The following example creates three UDAs: Designed, Checked, and Approved. assigned to PIPE, EQUIP, SHEET, and SPLDRG PDMS elements.

3.3.1

The UDAs will be

Creating a UDA World (UWRL)

When the Lexicon Dictionary database is created using the Training Setup, a Lexicon world called UWRLPROJECT/DICT is created. This database will be used during this training course. However, if a new UDA World is required it can be created by following the steps outlined here.

Navigate to the Dictionary World /* then click the right hand button of the mouse. From the resulting context menu select: Create > UWRLD: User defined attribute world

Use the Current Element Editor to set the Name and the Description as follows.

3.3.2

Name:

UWRL-TRAINING

Description:

UWRL Training

Creating a UDA Group (UGRO)

Navigate to the UDA World /UWRL-PROJECT/DICT.

From the right-click context menu select: Create > UGROUP: User defined attribute group

Using the Current Element Editor set the following: UDA Group Name

UGRO-TRAINING

Description

UDA Group Training


23


3.3.3

Creating a User Defined Attribute

Navigate to the UDA Group UGRO-TRAINING

From the right click context menu select: Create > UDA: User defined attribute

Enter the following values into the appropriate fields:

Name

DESIGNED

Description

Designed

Abbreviation Length

8

UDA Type

text

UDA Length

15

User-define name

DESIGNED

Reporter text

Designed

Select the Element Types

Icon.

This will display all available types. Reduce the selection displayed using the Filter Option.

Filter EQUIP Select EQUIPMENT followed by the Add to List button.


24


Repeat for the PIPE, SHEET and SPLDRG element types.

Select the OK button.

On the new UDA DESIGNED select: Create > UVALID: User defined valid value

Enter the following information: Description

JOE BLOGS

UDA VALUE

JB

The process should be repeated for: JJ - JIMMY JAMES, and FS - FRED SMITH. Also set the Limits or Valid values Optional flag to True.

The UDA should now be set as follows. In a similar way UDAs Checked and Approved can be created. Save work.


25


Exercise 2

Creating and Using UDA’s

Create the UDA’s Checked and Approved and assign them to “PIPE”, “EQUIP”, “SHEET” and “SPLDRG”. Check that you can add information in Design, Draft or Spooler. Set the Limits or Valid values Optional flag to TRUE on Designed and Checked but to False on APPROVED. In Design navigate to a Pipe and select Modify > Attributes…

Try setting :DESIGNED, :CHECKED and :APPROVED to valid and invalid values.


26

CHAPTER 4

4

User System Defined Attributes

A User System Defined Attribute (USDA) allows the administrator to place behaviour on a standard PDMS element. For example limits may be applied to attributes of top level elements within PDMS. A USDA allows the administrator to add the following behaviour to system attributes: 

Set valid values



Define limits



Hide attributes on forms



Category

The valid values and limits may be varied with element type. These values are defined by creating a USDA element in the dictionary database.

4.1

USDA Hierarchy UWRL

UGRO

In order to create a User System Definable Attribute (USDA) the user must navigate to a UDA Group (UGRO). USDA

ULIMIT

4.2

UVALID

USDA Definition

A number of fields are associated with the definition of a User System Defined Attribute. A brief description of each field is provided below.

 Name The name by which the USDA will be referred to in the PDMS modules.  Description A Text attribute which may be used to give a description of the USDA.  System Attribute Underlying system attribute to which the USDA is to be applied.


27


 Element types A logical attribute, if set to true the USDA will be applied to all PDMS elements with the attribute defined in USYSTY ELEL – an Array containing a list of PDMS elements to apply the USDA to.  UDA Category This field allows the administrator to group USDAs on the Attributes form within PDMS modules, e.g. UCAT ‘MYCATAGORY’. If UCAT is left unset then it has no effect.  Hidden On setting this logical attribute to True will indicate that the USDA will be hidden from the ‘Q ATT’ command and from the attribute form within PDMS. Querying of the individual UDA will not be affected by this setting.  UTEAMS If the UHIDE attribute has been set then the UTEAMS attribute can be used to indicate which teams the USDA will be available too. UTEAMS can hold an array of values.

4.2.1

USDA Limits and Valid Values

A USDA may own ULIMIT and UVALID elements to denote the limits and valid values. These are described in Valid Values and Creating a USDA.

4.3

Creating a USDA – A Worked Example

The following example will restrict the FUNC attribute on EQUIPMENT to be 'Heatx' or 'Pump'. Create a USDA as follows. A new UDA World is required, navigate to the Dictionary World /*. Using the right click context menu select: Create > UWRLD: User defined attribute world.

Use the Current Element Editor to set the Name and the Description as follows.

Name

USWRL-TRAINING

Description

System Attribute World


28


Navigate to the UDA World USWRL-TRAINING Using the right click context menu select: Create > UGROUP: User defined attribute group

Set the following: UDA Group Name

USDA-GROUP

Description

Training System Attribute Group

Navigate to the UDA Group USDA-GROUP Using the right click context menu select: Create > USDA: User system defined attribute

In a similar way to the creation of a UDA the following should be set:

Name

UFUNC

Description Set restriction on FUNC attribute on EQUI System Attribute

FUNC

Element Types

EQUIPMENT

On the New USDA UFUNC select: Create > UVALID: User defined valid value


29


Description

Pump

UDA VALUE

PUMP

Repeat the process for “Heat Exchanger”, HEATX

UFUNC is set as shown.

The following is an example of limiting the Temperature range on a Pipe and Pipe Branch.

Name

ULIMITTEMP

Description

Set Temp Limits on a Pipe & Branch

System Attribute

TEMP

Element Types

BRANCH PIPE

On the New USDA ULIMITTEMP select: Create > ULIMIT: User defined Limits

Description

Temperature Range

MINIMUM VALUE

-50

MAXIMUM VALUE

500


30


ULIMITTEMP should now be set as shown


31


Exercise 3

Creating and Using USDA’s

Using the described Worked Example create the USDA “UFUNC” and “ULIMITTEMP” and test them in Design. In Design Navigate to Equipment and Select Modify > Attributes….



Valid Values are available in a Pull down.

In Design, navigate to a Pipe and select Modify > Attributes…

Try setting Temperature to 50 and -200.


32

CHAPTER 5

5

User Defined Element Type

Within PDMS the standard set of elements are often used for a variety of purposes. A User Defined Element Type (UDET) allows an element to be created with a more meaningful name. UDET’s allow Designers to create real engineering items e.g. “Pumps”, “Towers” or Areas. UDETs are based on existing PDMS Item Types.

UDET Hierarchy

5.1

In order to create a User Defined Element Type (UDET) the user must navigate to the correct place in the Hierarchy, i.e. a UDET World (UDETWL) or UDET Group (UDETGR).

5.2

UDET Definition

A number of fields are associated with the definition of a User Defined Element Type.

A brief description of each field is provided in the sections that follow.

5.2.1

General

The fields available in the General section are described below. 

Name This allows the user to enter a valid name for the UDET in the Lexicon database. Special characters are not allowed and only alphabetic characters are allowed.



Description This allows the user to add a descriptive phrase to the UDET.


33


5.2.2

Basic Definition

The fields available in the Basic Definition section are described below. 

User-defined name This allows the user to enter a name that will be given to the element for which the UDET is created. It should be set to the Name of the UDET. But the user is allowed to change the UDET Name if required. Special characters are not allowed for the UDET name and only alphabetic characters are allowed.



Base Type This allows the user to select the System Type that the UDET will be based on.

There is a filter option to assist with element selection.

5.2.3

UDET Hierarchy

The fields available in the UDET Hierarchy section are described below. 

Owner Types The UDET Owners list is automatically populated with the list of valid owners based on the Base Type selected.

The User can remove valid owners from the list using the tick box. There must be at least one owner.


34




Member Types The UDET Members list is automatically populated with the list of valid members based on the Base Type selected.

The user can remove valid members from the list using the tick Box.

5.3

Creating a User Defined Element Type (UDET) – A Worked Example

In the following example a Tank and Tower are created based on a PDMS base type of Equipment.

5.3.1

Creating a UDET Element World (UDETWL)

Navigate to the Dictionary World /*. Using the right-click context menu select: Create > UDETWL: User defined element world

In the Current Element Editor enter the following:

5.3.2

Name

TRAINING/UDETWL

Description

Training Detail World

Creating a UDET Group (UDETGR)

Navigate to the UDET World, then using the right click context menu select: Create > UDETGR: User defined element group


35


Use the Current Element Editor to set the following:

5.3.3

Name

EQUIP/UDET/GROUP

Description

Equipment UDET Group

Creating a User Defined Element Type (UDET)

Navigate to UDETGR EQUIP/UDET/GROUP

From the right click context menu select: Create > UDET: User defined element

Use the Current Element Editor to set the following: Name

TANK

Description

Tank

User-defined Name

TANK

Base Type

Select

Icon

This will display all available types. The selection can be reduced using the Filter option. Filter EQUI Select EQUIPMENT

Click the OK button.

The Owner types, Member types and Hidden attributes can be left set to default.


36


The operation can be repeated for TOWER.


37


Exercise 4

Creating and Using UDET’s

Using the above example, create a Tank and Tower element based on Equipment and test its use in Design. In Design navigate to an Equipment Zone for example /ZONE-EQUIPMENT-AREA01 and in the Equipment Application Select Create > Standard Equipment… – Select Tank from the User Define Type Pull down.

The Command Line Syntax in Design would be NEW :TANK.


38

CHAPTER 6

6

Status Control

Throughout a projects lifecycle a typical AVEVA Plant project contains a number of design disciplines and processes. In order to maximise productivity and minimise costs it is essential to control and communicate the progress of design activities. The Status Control utility has been developed to assist designers with this process.

6.1

Overview

The Status Control utility is a highly configurable tool that allows the user to control and report on the progress of model objects. It works by defining a number of Status Values, that describe the current state of a model object, and applying them to appropriate elements in the Constructor Modules (i.e. Design, Draft, Paragon, etc.). Status Values can perform two functions. They inform the user of an objects current status and they can be used to influence subsequent design activities. The terms used to describe Status Values are defined by the user. They may represent project milestones, WBS elements, percentage completion rates, or they may be simple descriptive terms. The user can also define the object types that the Status Values will be applied to. The object type will vary in each Constructor Module e.g. in Draft the object type may be DRWG but in Design the object type could be PIPE, EQUI, etc. By applying Data Access Control (DAC) the administrator can impose restrictions on model objects that have reached a particular status. For example, certain activities, such as modifying an objects position, may be prohibited once a certain status is reached. Model objects that have one or more status values assigned to them are considered to be Controlled Objects. It may not be necessary to control all instances of a model object type. As such the status control tool allows the user to select which instances of the model object type will be controlled.

6.2

The Status Control Data Model

The diagram below illustrates the relationships that are utilised in AVEVA Plant by the Status Control tool.


39


Status Values are created and stored in the dictionary database hierarchy. Within the Constructor Modules a Status Link hierarchy is referenced by model objects. The Status Link also references the Status Value held in the dictionary database.

6.3

Hierarchy Overview

Unique hierarchy structures are required in both Lexicon and the Constructor Modules in order to successfully implement the status control utility. The nature and function of the hierarchy structures are considered in the sections that follow.

6.4

Status Control Hierarchy - Lexicon

New hierarchical elements have been created in Lexicon to facilitate Status Control. Status World elements (STAWLD) own Status Definitions (STADEF) which in turn own Status Values (STAVAL). An optional level of hierarchy, sitting immediately below the Status World, is the Status Group (STAGRP). Status Worlds have an administrative function. They may store a number of status groups and definitions. Each group or definition may be associated with a project, design discipline, or PDMS module. Status Groups are an optional level of hierarchy. They allow a number of definitions to be grouped within a status world. This may be useful where a number of workflows exist within a particular discipline (i.e. different checking requirements within a design discipline). Status Definitions allow the user to set which model object types the status values will be applicable to in the constructor modules (e.g. PIPE, EQUI, etc.). An initial status value, used when a model object is first controlled, can also be set in the Status Definition. Status Values provide the descriptive terms and numerical values that will be applied to model objects as they progress through the design process. An objects status changes throughout the design process; therefore it is necessary to update the status value associated with it. This is achieved by setting valid transition values for each status value. From the valid transitions, default settings to Promote and Demote the objects status can then be set. Only one status value can be set for either the Promote or Demote default; however the object can have any defined status values set as a valid transition.


40


6.5

Status Control Hierarchy – Constructor Modules

Most administrative tasks relating to Status Control are carried out in Lexicon. However additional hierarchy and pseudo attributes have been introduced to the constructor modules. Administrators need to be aware of these elements if DAC’s is to be implemented or further customisation is carried out. The hierarchy employed for status control within the constructor modules is hidden from the user. A Status Link World (STLNKW) owns a number of Status Links (STALNK). Contained within the STALNK are a number of pseudo attributes that are used to reference both status values and model objects.



6.6

A comprehensive list of pseudo attributes relating to status control is supplied in the Status Control Reference Manual. Simple examples of customisation and DAC’s are provided in later sections.

Implementing Status Control – A Worked Example

The focus of this example is the creation of the hierarchy elements required in Lexicon. The hierarchy required in the constructor modules is globally distributed with the model objects. As such, Administrators should only ever need to reference such elements, not create them. This example will consider a simplified workflow that could be implemented for pipe modelling as shown below.

Prior to creating the hierarchy in Lexicon the Administrator must ensure that the MDB selected contains a Dictionary database that can be written to.

www.aveva.com


41


6.6.1

Creating Status Worlds

To create the necessary hierarchy navigate to world level then click the right mouse button. From the context menu select Create > STAWLD: Status Configuration world.

In the Current Element Editor enter the details provided below. Name: PIPE-WORKFLOW Desc: PIPE WORKFLOW STATUS MANAGEMENT

A new STAWLD element will be created and displayed in the Dictionary Explorer.

6.6.2

Creating Status Groups

The workflow in this example caters for pipes that require stress tests and specialised supports. The following exercise will allow for pipes that only require layout checks. To distinguish between the two workflows, two Status Groups will be created. One for Critical Pipes, requiring stress and support checks, and one for Non-Critical Pipes. This will allow users in the design module to set a suitable Focus Status to manage each type of pipe.

With the newly created STAWLD selected as the CE, click the right mouse button. From the context menu select: Create >STAGRP: Status definitions group.


42


In the Current Element Editor enter the details provided below. Name: CRITICAL-PIPES Desc: FOR PIPES WITH STRESS TESTS A new STAGRP element will be created and displayed in the dictionary explorer. A second STAGRP is required for the exercise that follows (for Non-critical pipes). In a similar manner create a second STAGRP. In the Current Element Editor enter the details provided below. Name: NON-CRITICAL-PIPES Desc: LAYOUT CHECKS ONLY

The two STAGRP elements will be displayed in the Dictionary Explorer and the hierarchy should look similar to this:

6.6.3

Creating Status Definitions

With the newly created STAGRP CRITICAL-PIPES selected as the CE, click the right mouse button.

From the context menu select: Create > STADEF: Status Definition. In the Current Element Editor enter the details provided below. Name: CRITICAL-PIPE-DEFINITION Desc: WORKFLOW FOR CRITICAL PIPES

At this stage the Initial Status for controlled model elements cannot be set, as no Status Values have been defined. For the time being, this field will be left blank. The STADEF allows the user to define the type of model elements that can be controlled in the constructor modules. This is achieved by setting the Controllable Element Types field in the Current Element Editor. Click the left mouse button when the pointer is in the blank text box adjacent to the Controllable Element Types field. A browse button will be displayed. Selecting the browse button will display the Select Element Types form.


43


All valid element types are displayed in the upper half of the form. Above them is a filter text box allowing the user to refine searches for particular element types. As the status definition will be used for Pipes in the Design application type PIPE in the Filter text box. In the scrollable list below the Filter field select the Pipe element. The Add to List button will now be active. Click the Add to List button to add the Pipe element type to the Chosen Element Types area of the form. Click the OK button. The Current Element Editor will update the STADEF to show a Controllable Element Type of PIPE.

6.6.4

Create Status Values

With the necessary hierarchy and controllable elements defined the first status value can now be created. With the newly created STADEF selected as the CE, click the right mouse button. From the context menu select: Create > STAVAL: Status Value. In the Current Element Editor enter the details provided below. Name: WORK-PENDING Desc: AWAITING RESOURCES Both the name and description fields can be viewed in the constructor modules. As such, the description field can be used to supplement the name given to the status value. In addition to the name and description fields a Numerical Value can also be associated with a Status Value. The value used may indicate a task completion percentage, a work breakdown code, or other similar parameters. In this case, the numerical value will represent how far through the design process (between 0 and 100) a particular pipe is. In this case, the Work Pending status value represents a period where work has not started. As such, the numerical value will be left at zero. The Transitions area of the form governs the relationships between Status Values. As this is the first Status Value this area will be left blank for now. Transitions will be set when all required Status Values have been created.


44


In the Dictionary Explorer, navigate to the STADEF CRITICAL-PIPE-DEFINITION. Click the right mouse button and select: Create > STAVAL: Status Value. In the Current Element Editor enter the details provided below. Name: DESIGN Desc: PROVISIONAL LAYOUT Numerical Value: 30 In a similar manner create the following Status Values: Name: LAYOUT-CHECKS

Name: ISSUED

Desc: CONFIRM LAYOUT

Desc: ISSUED TO DRAFT TEAM

Numerical Value: 60

Numerical Value: 100

Name: STRESS-CHECKS

Name: RE-WORK

Desc: CONFIRM STRESS

Desc: ADJUSTMENTS REQUIRED

Numerical Value: 70

Numerical Value: 50

Name: SUPPORT-CHECKS Desc: CONFIRM SUPPORTS Numerical Value: 80 The status of a model object should be controlled in a series of suitably sized steps that are appropriate to the work flow. For example, there is little benefit in changing the status of an object from Not Started to Completed in one step. To ensure that users make suitable status changes, Valid Transitions should be defined for each Status Value. Due to the cyclic nature of design processes the work flow associated with a model object may be quite complex. To address this difficulty it is possible to associate a number of Valid Transitions with each Status Value. Make the STAVAL LAYOUT-CHECKS the current element. Click the left mouse button when the pointer is in the blank text box adjacent to the Valid Transitions field. A browse button will be displayed. Selecting the browse button will display the Select Valid Status Transitions form. In this simple example two workflows are possible from this status value. If the work is accepted, the status may be changed to show that layout checks have been completed and stress checks can now be considered. If the work is rejected, adjustments will be required and re-work must occur. Selecting the STRESS-CHECKS and RE-WORK checkboxes will account for these two scenarios. Click the OK button to accept the transition values. The STAVAL will update to show the valid transitions.


45


In the constructor modules the user will also be able to edit model objects by promoting or demoting the status. The promotion and demotion statuses are set in the Transitions area. An option list is provided adjacent to the Promote field. Selecting the drop down arrow will display the Valid Transitions for the STAVAL. In this instance select the Status Value STRESSCHECKS. The same process should be repeated for the Demote field, this time setting the Status Value to RE-WORK. The Current Element Editor will update to reflect the new values. Transition settings need to be made for each of the Status Values. Return to each Status Value and set the following valid values and Promote/Demote default settings: Name: WORK-PENDING

Name: SUPPORT-CHECKS

Valid Transitions: DESIGN

Valid Transitions: ISSUED, RE-WORK

Promote: DESIGN

Promote: ISSUED

Demote: Leave Blank

Demote: RE-WORK

Name: DESIGN

Name: ISSUED

Valid Transitions: LAYOUT-CHECKS

Valid Transitions: Leave Blank

Promote: LAYOUT CHECKS

Promote: Leave Blank

Demote: Leave Blank

Demote: Leave Blank

Name: LAYOUT-CHECKS

Name: RE-WORK

Valid Transitions: RE-WORK, STRESS-CHECKS

Valid Transitions: LAYOUT-CHECKS

Promote: STRESS-CHECKS

Promote: LAYOUT CHECKS

Demote: RE-WORK

Demote: Leave Blank

Name: STRESS-CHECKS Valid Transitions: RE-WORK, SUPPORT-CHECKS Promote: SUPPORT-CHECKS Demote: RE-WORK


46


Once all the transitions are set save work then switch to the Design module. Use the login details provided by the Trainer. They will typically be similar to this:

6.6.5

Project

Training

Username

A.PIPER

Password

A

MDB

A-PIPING

Testing Status Control in Design

In the Design module, select Display > Status Controller… from the main menu. The Status Controller form will be displayed.

The Status Controller form will initially be blank unless Status Layouts have been created previously. A Status Layout will be created to track the progress of a number of pipes. Select the Status Layout option list and select the New Layout… option. The Select Status Columns form will be displayed. Select the checkbox adjacent to WORKFLOW FOR CRITICAL PIPES.



This form displays the description associated with the Status Definitions created in Lexicon. Selecting the checkbox will expand the column listing available for the status definition. By default, Status Layouts are initially created with up to four columns. Three of the columns reflect fields populated when the Status Values are created in Lexicon; Name, Description, and Numeric value. The fourth column allows comments relating to status changes to be recorded. The user can select which columns are displayed by deselecting checkboxes as required. If additional columns are required to display other PDMS attributes (e.g. Owner) they can be added after the initial layout is created. Leave all columns selected then click the OK button. The Status Controller form will be populated with all PDMS elements that have their Type set to Pipe, as this was the element type specified for this Status Definition in Lexicon. © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

www.aveva.com 47


Save the layout by selecting the Save Status Layout button from the Status Controller form. The Save Layout As form will be displayed. Enter the name Detailed in the text field then click the OK button. The Status Controller form will update to reflect the name of the saved layout. Although the layout contains a range of pipes, none of them are controlled by the Status Definition at this stage. To apply the status definition to the pipes select a range of pipes in the grid area of the Status Controller form (now titled Detailed).



Standard windows Shift and Control key functionality can be used in this grid.

With the mouse pointer over one of the selected grid entries click the right mouse button. From the context menu select the Edit Status… option.

From the resulting Status form select AWAITING RESOURCES from the Value option list then click the OK button. The Status Controller form will update to reflect the new status of the controlled pipes. Select one of the pipes then select Promote from the right click context menu in the Status Controller form. Continue modifying the status of the controlled pipes, checking that promote and demote commands update the status to the correct value.


48


Exercise 5 – Creating Status Values Return to the Lexicon module and open the STAWLD PIPE-WORKFLOW. Navigate to the STAGRP NON-CRITICAL-PIPES and create the necessary definitions and values to support the workflow below.

Test the Status Definition in Design. Try creating a Status Focus for Critical and Non-Critical pipes within a single Status Layout.


49


6.7

Status Control Customisation

Status Control supports an extensive range of customisation options in the areas of Data Access Control, PML and C#. Extensive consideration of this topic is outside the scope of this training course, however a brief overview of possible functionality is provided in the sections that follow.



For details of customisation requirements please refer to the Status Control Reference Manual.

6.8

Data Access Control

The Status Control utility can be coupled closely with Data Access Control to preserve data integrity. A variety of activities can be restricted. For example, only users with particular access rights may change the status of an object once it has reached a certain stage; or, only certain users can assign or remove status from a controlled object. Suitable error messages can also be generated to alert the user of any restriction. Provided below are two example Data Access Control rules. They have been created on the basis of Roles where the first PEROP grants all rights on all elements and attribute classes, then successive PEROP’s deny some rights under specific conditions.

6.8.1

Prevent Modification of an Object of a Certain Status

It may be desirable to ensure that a model object cannot be changed once it has reached a certain status value. For example, if an item of equipment was very close to being issued but needed sign off, no further modifications would be required. For the purpose of this example, this state could represent a Design Status of 90%. The Administrator can cater for this situation by creating a PEROP that denies modify and delete operations on equipment for all attributes, with the qualifying condition that the Design Status is greater than or equal to 90%. The syntax for the condition would be: COND ( ATTRIB STVNUM(ID /DesignStatus ) GE 90 )



Expressions relating to Status Values usually require the name of the owning Status Definition to be provided as a qualifier. In this example /DesignStatus is the name of the Status Definition.

A suitable error message would also need to be returned to the user e.g. DAC: You may not modify an object that is ready for issue.

6.8.2

Prevent Promotion of an Object by Certain Users

It may be necessary to restrict which users are capable of promoting a model object once the object reaches a certain status value. For example, a model object has been promoted to a Check Stress status by a designer, but the Administrator wants to ensure that only a supervisor promotes the status to Checked. In this case the Administrator should create a PEROP that denies modify and delete operations on STALNK (status link) elements for attribute VALREF (status value reference) with the qualifying condition that the Design Status is currently at Check Stress. The syntax for the condition would be: COND ( ATTRIB OWNER OF VALREF EQ ID /Design Status AND ATTRIB DESC OF VALREF EQ ‘Stress Check’ ) As with the previous example, a suitable error message should be provided to the user e.g. DAC: You may not modify an object that awaits stress checks.


50


6.9

Auto Colours

Status Values can be used in the Element Rules for Auto Colours. If suitable Element Rules are defined, and Auto Colour rules added, then status distinctions can be made in the 3D model. For example, uncontrolled equipment could be shown in red, while a range of other colours could be used to reflect key status values. Typical syntax for element rules are shown below.



The use of Auto Colours is not applicable to Status Control definitions that are applied to the DRAFT application.

6.9.1

Equipment with Design Status Not Controlled

If the user wishes to show equipment items that are not controlled in a different colour the element rule syntax would be: Rule Name: Equipment Not Controlled Types: EQUI Rule: badref( attrib stvval( /EquipmentDesignStatus ) ) Where EquipmentDesignStatus is the name of the STADEF defined in Lexicon.

6.9.2

Equipment with Design Complete

If the user wishes to show equipment items that are completed in another colour the element rule syntax would be: Rule Name: Equipment Complete Types: EQUI Rule: attrib stvnum( /EquipmentDesignStatus ) eq 100 Where EquipmentDesignStatus is the name of the STADEF defined in Lexicon.

6.10 PML Customisation Status Control operations can be carried out using PML. Any operation that can be carried out using the Status Controller can also be done using appropriate PML objects and syntax. By incorporating an event mechanism, specific company and project requirements can be accommodated. User methods can be added as event handlers and called with single array arguments. Both Status change events and database change events can be catered for in this way. Status data can be manipulated using the PML object statusProjectHandler.pmlobj. This object encapsulates a number of core routines that could also be used directly.



Please refer to the Status Control Reference Manual for further details.

6.11 .Net Customisation (C#) Customisation can be undertaken in .NET applications. This may be as an alternative to, or in conjunction with the PML customisation. Where such customisation is carried out using C#, a number of Classes are available to the user. They have similar functionality to the PML objects and can be used status values and events.



Please refer to the Status Control Reference Manual and PDMS .Net documentation for further information.

www.aveva.com


51


6.12 Status Control Customisation – A Worked Example For the purpose of reporting project progress, it is often desirable to run an overview status definition in conjunction with a detailed status definition. Returning to the workflow considered in the previous worked example, an additional overview status definition will be added. The diagram below shows the relationship between the two status definitions.

Design Phase I - Initial design activities, ending when a pipe is promoted to the status value Stress Checks. Design Phase II - Starts when a pipe has the status value set to Stress Checks and finishes when the status value Issued is achieved. Design Phase III – Achieved when the status value Issued is reached. Make the Dictionary World the CE then select Utilities > Training Setup…from the main menu. From the Lexicon tab of the Training Setup form, select the Add OVERVIEW Pipe Status Definitions checkbox then click the Apply button.

The Status World is re-created with an additional Status Definition for the Overview process. The Overview status definition is also set to control pipes. Although the Status Definitions are contained within the same Status World there is no means to link them directly in Lexicon.


52


The PML Library within PDMS holds a common object created for use with the Status Control utility. The PML Object statusProjectHandler contains a number of methods that allow automated events to be initiated based on changes made to an element. For the purpose of this exercise, adjustments will be made to the PML Object statusProjectHandler that will allow the Overview Status Definition to update based on changes in the Detailed Status Definition. Navigate to the PMLLIB folder in the PDMS installation, typically: C:\AVEVA\Plant\PDMS12.\PMLLIB\common\objects Open the common folder, followed by the objects folder. Navigate to the statusProjectHandler.pmlobj file and click the right mouse button. From the context menu select the Edit option.



If an edit facility is not available in the context menu, open the file using Notepad or a similar text editor.

The methods defined in the file are listed at the top of the file. After each method is an area for customisation and in some instances example syntax. This exercise uses the afterStatusChange (ARRAY) method. Navigate to this area of the file. Two customisations are included in this area of the file. The first customisation is an example of the methods potential use and is supplied with PDMS. The second customisation has been created for training purposes.

The PML expressions used check the Status Name of one Status Definition and, if it matches a set value, assigns or sets the Status Name in another Status Definition. When this process occurs a comment is added in the Status Layout. Remove the $( and $) symbols from the top and bottom of the customisation text then save and close the file. The customisation text is now active in the file.


53


Exit PDMS then Re-Enter the Training project through the Design module using the details provided by the Trainer. They will typically be similar to this:

Project

Training

Username

A.PIPER

Password

A

MDB

A-PIPING

If the Status Controller form is not displayed, open it from the Display menu. Select the Detailed layout from the Status Layout option list. Select all the pipes previously controlled. From the right click context menu select the Remove Status option. Click the Yes to All button on the subsequent confirmation message. A new Status Layout is required for the overview status definition. From the Status Layout option list select New Layout. From the subsequent form, select the checkbox adjacent to HIGH LEVEL DESIGN UPDATE. Deselect the checkbox adjacent to WORKFLOW FOR CRTICAL PIPES then click the OK button. Click the Save Status Layout button and name the layout Overview. Within the Overview layout select the first five pipes. Click the Edit Status button and set the pipes to INITIAL DESIGN ACTIVITIES. Return to the Detailed status layout and select the first five pipes in the layout. Using the Edit Status button set the status to AWAITING RESOURCES. Select the first pipe in the list and promote the status of the pipe until it reaches the status value CONFIRM STRESS. Navigate back to the Overview status layout. The promoted pipe should now be at the status value DESIGN-PHASE-II. The Comment column will be populated, notifying the user that an update has occurred due to a changed status value within the CRITICAL-PIPE-DEFINITION status definition.

Continue to promote other controlled pipes and check that the correct update occurs in the Overview status layout.


54

CHAPTER 7

7

Database Views

PDMS element information, that may be required on a deliverable document, is not always stored on the element itself. The required information can be distributed over a number of associated elements. For example, the primary information for a nozzle is stored on the NOZZ element itself, but additional connectivity information may be stored on the connected Branch and/or Pipe elements and ownership information stored on the Equipment, Zone and/or Site elements. A Database View is a method of collecting all of this information into one common Element that can be reused throughout the project.

7.1

Overview

A Database View defines a table for retrieving/viewing and manipulating data in the database; the data may be derived from a single element or multiple elements. There is a row in the Database View table for each element that has a particular element type and meets the criteria defined by attribute filters. These Filters are similar in concept to those in the search grid. In addition, if element match criteria cannot be expressed using attribute filters, it is possible to define an expression for evaluation. For example, a Database View could be derived from all Equipment elements in the current MDB with a description of “Vessel”. The user specifies the required columns; each being a database attribute or an expression run against the Equipment element. In addition, the user can specify how to navigate to related elements, such as the owning SITE or ZONE, and derive further columns from those elements. Database Views are defined and modified in the DICTIONARY databases using PDMS Lexicon and are stored under a Database View World element (DBVWWL). However, ad-hoc working definitions may be stored in a local user file. These methods allow: 

User defined Database Views for reports, and for testing.



Project defined Database Views for reports, shared via Global.



Application defined Database Views for specialist applications.

Database Views are primarily used with in the Plant Design modules for creating reports with the Report Designer and within Lexicon module as an administrative tool to check the validity of a Projects Dictionary.



They are also used extensively by the Engineering TAGS module

There are three types of Database Views available: Element Views

An Element View is automatically created and maintained by the system. These Views are provided for all base Element Types within the project schema and are available to all Users.

Project Views

A Project View is a user-defined View of the data and is stored within a Lexicon dictionary database. The Views are available to all Users. These Views may contain more complex data i.e. the combining of an element’s attributes (UDA and Pseudo), from associated items, and attribute based expressions.

User Views

User Views may be copies of Project or Element Views, or views an Administrative User has created and stored locally. It is envisaged that an Administrator would create and refine individual User Views prior to exposing the View to all Users by copying it to a project dictionary database, where it would become a Project View.


55


7.2

Database View World (DBVWWL) Hierarchy

In order to create a Database View (DBVW) the user must first navigate to the correct location within the Lexicon hierarchy. A DBVW may be created directly under a Database View World (DBVWWL), or under the administrative element’s Database View Group (DBVWGR) or a Database View Set (DBVWSE), as shown below. The administrative elements allow the user to group similar items together.

DBVWWL

DBVWGR

DBVWSE

DBVW

DBVW

DBVW

DBVWWL (Database View World)

This is an administrative element for grouping Database Views and associated owing items. A project must have a DBVWWL element within its Dictionary Databases to enable the creation and use of Database Views within that project.

DBVWGR (Database View Group)

This is an administrative element construct that can only be seen within the Dictionary Explorer. It allows an Administrator the ability to group Database Views in ways that facilitate administration of them in the Dictionary database.

DBVWSE (Database View Set)

This is a collection of views that are defined as a set for a given workflow or common purpose. As such a DBVWSE is visible to the user when selecting database views and may be used within an application as a set of views for a given task/report/workflow

DBVW (Database View)

A Database View element defines the table for retrieving/viewing data table constructed from the database hierarchy elements.

7.2.1

Creating Database View Administrative Elements

With the Dictionary World selected as the CE, the user can create a new Database View World using either the main Create menu or the right click context menu in the Dictionary Explorer.


56


A Database View Group (DBVWGR), and a Database View Set (DBVWSE) are created in a similar way.

An administrator can provide the DBVWWL, DBVWGR, and DBVWSE elements with a Name and a Description using the Current Element Editor so that their purpose can be easily identified at a later stage. Because the DBVWSE elements are exposed to general users elsewhere within PDMS, it has an additional attribute User-defined Name. This is the name that the users will see and use.

7.3

Database View (DBVW) Hierarchy

As discussed before, a Database View is a view on a single element or on the associated data of multiple elements, in a tabulated form. A Database View can contain various hierarchy elements that retrieve and manipulate the data. These elements are described in detail later The diagram below shows the various elements that can be used within a Database Views definition.



A Database View can have multiples instances of its child elements, (dashed) except for a Creation Rule (CRERUL) which it can only have one occurrence of.

DBVW

ATTFIL

ATTCOL

EXPFIL

All DBVW elements except ATTFIL and EXPFIL

SRCELE

EXPCOL

CRERUL

SETATT

SETSTA

SETPAR

TESTEX

All the elements that can belong under a Database View element have a number of fields. These fields are grouped into categories. Each element has a General category, which is common, plus a number of fields that are system generated values and cannot be directly changed by the user (e.g. Owner). These system fields appear in a lighter colour than fields that can be edited directly.


57


Fields that can be edited directly include:

7.3.1



Name The user can enter a valid name for the Item Type.



Lock This field determines whether or not the fields defining a UDA are locked. The field can be set to True (locked) or False.



Description A brief description of the Element Type can be provided to assist users. This field is not available on Element Types of the Database Views that are associated with UDAs due to the UDA possibly having a description.

Creating Database View

With one of the Database View Administrative Elements selected as the CE, the user can create a new Database View using either the main Create menu (Create > DBVW: Database view) or the right click context menu in the Dictionary Explorer.


58


In addition to containing general fields, a DBVW has a number of Basic Definition category fields that are used to define the view’s contents and behaviour.

The User-defined name field allows the user to give the Database View a ‘friendly’ name that all the users will see throughout the PDMS product suite when they are viewing Project Views. The Auto Creation setting determines whether items can also be created using the view.



The ability to create items using the view is only available within the AVEVA Engineering TAGS module.

The Element types field is where the user selects what elements the view is to contain. The Element types can either be manually typed into the field separated by spaces, or if the (…) ellipsis button is selected the Select element types form will be shown.

The user adds and/or removes the Chosen element types by selecting the elements in the appropriate lists and then using the respective Add to list or Remove selected buttons to modify the list of Chosen element types. The Filter: textbox allows the user to filter the top list of available Element Types. This list will include any UDETs that have been defined in the Dictionary database.



As discussed before a DBVW can be based on multiple Element types.

Click the OK button to close the form.


59


7.3.2

Creating a Database Views Elements

With a Database View element selected as the CE, the user can create the elements that define the database view’s data contents. This can be achieved by using either the main Create menu or the right click context menu in the Dictionary Explorer.

7.3.2.1 ATTFIL (Attribute Filter) This element defines a filter that an element’s specified attribute(s) must match to be included in the current view. Both UDAs and Pseudo attributes can be filtered. A filter is defined in the Basic definition fields of the ATTFIL and includes the following fields: Attribute: name of the attribute to filter. Filter operator: a predefined list of operators which determine how the attribute is to be qualified.



All of the available operators are shown here:

Filter value: the value the attribute must match to be true. For example, to only populate the view with items that have ‘W’ in their name the Basic definition is set to: Attribute:

NAMN

Filter operator:

Contains

Filter value:

‘W’



This filter mechanism is the same as the attribute filter that is available within the PDMS search grid.

7.3.2.2 EXPFIL (Expression Filter) These define a Boolean expression that must evaluate to true for an element to be included in the current view. The expression can be a PML 1 or an XPath 1.0 expression.

The Basic definition is the Expression itself and the Expression type; whether it is PML or XPATH.


60


Some examples of valid PML 1 and XPATH expressions are shown below: Example PML Expressions

Elements that would be listed in the Database View

PSPEC EQ /A3B

Items with a Pipe Spec. of /A3B.

HBOR GE 100

Items with Head Bore greater or equal to 100 NB.

SPREF EQ /DIN-SPEC/HE300A

Sections with a Specification Reference of DIN Spec HE300A.

FUNC NE ‘FUTURE’

All Equipment whose Function is not equal to FUTURE.

:MANUF EQ ‘Best Pumps Inc.’ OR :MANUF EQ ‘Better Pumps Ltd.’

All Items where the UDA :MANUF (Manufacturer) is either Best Pumps Inc. or Better Pumps Ltd.

Example XPATH Expressions

Elements that would be listed in the Database View

string-length(@RPTX) = 0

All Items with a RPTX (Reporting Text) sting length eq zero character’s

7.3.2.3 ATTCOL (Attribute Column) This defines a column that returns the attribute value from the current source element(s).

To define an ATTCOL the Attribute field in the Basic definition is set to the name of the database attribute that is to be returned to the view; this can be a UDA or Pseudo attribute. If the attribute is a qualified attribute then the qualifier must be entered into the Attribute Qualifier field. An example is a Status Control attribute, where the Status Value Description (STVDSC) is a qualified value of the Status Definition /EquipmentDesignStatus element.

The User-defined name field allows the administrator to add a more user friendly / purposeful name that will make the column more recognisable to the users. If the field is left as unset then the attributes Description field value will be displayed. The Read only field determines whether the users can interact back to the database and directly change an element’s attribute value via the current database view.


61


7.3.2.4 EXPCOL (Expression Column) This defines a column that is based on an expression result. These columns are read only. The expression can be a PML 1.0 or an XPath 1.0 expression. In the Basic definition of the EXPCOL element the user enters the required PML or XPATH expression in the Expression field. Depending on the syntax of the expression, the user must select the relevant Expression Type; either PML or XPATH from the pull-down list. The User-defined name field allows the administrator to add a more user friendly / purposeful name that will make the column more recognisable to other users. If the field is left as unset then the attribute’s Description field value will be displayed.

Depending on the evaluated result of the expression, the user must select the relevant UDA type from the pulldown list of available types. Failure to select the correct UDA type may result in the column of the view displaying no information, or returning an error.

7.3.2.5 SRCELE (Source Element) Instead of using an expression to derive column(s) in the current view from other database elements from the base element, a SRCELE can be used to navigate to the source element from which the attributes or expressions required in the current view are taken. Using a SRCELE helps to separate navigation around the database source elements and can simplify the definition of the columns The SRCELE creates a sub-view from its position in the hierarchy. All of the attributes and expressions are local to it, rather than being derived from complicated expressions that navigate and return results. An example may be a BRANCH report requiring information from the owing PIPE. Rather than create multiple EXPCOL’s that are in the format of of PIPE, a single SCRELE could be created and all of the attributes that are required can be created as ATTCOLs. The element of a SRCELE’s Basic definition are the Expression field, which is the navigational expression; this could be PIPE to navigate up to the owing PIPE, or OWNER of OWNER to navigate up two levels of the hierarchy. The Expression type field informs the system the type of syntax that has been entered into the Expression field. This can be either PML or XPATH and is selected from the pull-down option list. The Auto Creation setting determines whether items can be created within the actual view itself.



The ability to create items within a view is only available within the AVEVA Engineering TAGS module.


62


It is possible to create nested SRCELE items. For instance, if an example DBVW base element type was a Design INST element, the first SRCELE could navigate to the BRANCH element, and in turn another SCRELE at the BRANCH level may navigate to the PIPE element and again to the ZONE element before finally navigating to the SITE element. An example of the DBVW hierarchy for this type of navigation is shown here. At each level an ATTCOL element has been added to display the NAME.

7.3.2.6 Other Element Types that are available There are additional element types that a Database View can contain however; these are currently only used by the AVEVA Engineering TAGS module. For information these are listed below with summarised descriptions of what they are used for.



For more detailed information see the AVEVA Training Guide TM-3552 AVEVA Plant Tags (Admin)

Item Type

Description

CRERUL (Creation Rule Element)

Used to allow the definition of creation rules for creating row elements and column elements within a database view. All SRCELE’s are created with one but are not used.

SETATT (Set Attribute Rule)

A rule used to set an attribute when an element is created. If the value expression is left unset then the application or user are prompted for input.

SETPAR (Set Parameter Rule)

A parameter for use when executing rules to create elements within the database view.

SETSTA (Set Status Rule)

Set the status definition to apply to an element when created in the database view.

TESTEXP (Test Expression)

An expression used to return a Boolean result for the SETATT and SETSTA rule components

7.4

Database Views Editor

To help the user with the creation and modification of Database Views there is a Database Views Editor available within Lexicon module. The Database Views Editor does not need any of the Database View administrative elements to be created before allowing the user to create a Database View. It will automatically create an unnamed DBVWWL (Database View World) element in the first available Dictionary database in the current MDB. All DBVWs created by the editor are created within same Database View World. If the administrator requires the DBVWs to be in different DBVWWLs then they must first navigate to the relevant position in the Dictionary Explorer and create the Database View manually using either the right mouse menu option, or the Create menu option from the main menu.


63


7.4.1

Displaying the Database Views Editor

To display the Database Views Editor select Display > Database Views Editor The Database Views Editor form is shown below:



The User can undock the from the Lexicon MDI window by double clicking anywhere along the forms title bar, to re-dock the form double click anywhere along the forms title

When the form is displayed, the user is presented with the current project’s Database Views - listed in the Views section of the form under the Views tab. To change the type of Database Views that are listed the user selects the pull-down list in the View Definition Set section of the form and selects one of the options available, i.e. Element Views. This will repopulate the Views tabs list with all of available Database Views of the selected type.


64


The user can filter the list of views that they are presented with by changing the Database Types Filter pull-down option. For example, to display only the Views of elements that can exist within a PDMS Design Database, the user would change the Database Types Filter pull-down to Design.

Within the Views tab list, a right click context menu has a number of options. These include the ability to create New Views, create new View Sets, as well as Deleting, Renaming and Copying existing views.

If the View Definition Set is set to Project Views, because the Database Views Editor is independent from the Dictionary Explorer there is also an option Navigate to. This updates the Dictionary Explorer CE to the selected Database View in the editor. When a Database View is selected in the View tab list, it’s General and Basic definition category field information is displayed within the View Detail section of the form as shown below:


65


Each of the tabs in the View Detail section of the form allows the user to define the Database View’s contents. The editor helps the user to add, delete and modify the Database Views hierarchal elements in a user-friendly way.

7.4.1.1 User Views As discussed earlier, User Views may be copies of Project or Element Views, or Views an Administrative User has created and refined before exposing to all Users by copying it to a Project Dictionary Database as a DBVW. The difference between a User View and the other views discussed is that the definition is stored in a file on the file system and is not stored in any of the PDMS databases. In addition, they can only be accessed and modified using the Database Views Editor. The Users Views are stored in a separate file for each project that the user has access too; these are, by default, stored in the folder %PDMSUSER%\\Data\Database Views within a file called DatabaseViews.xml. Additional User Views from different projects can be accessed by selecting the Open link button in the View Definition Set section of the Database Views Editor form. A windows open file form is displayed and may be used to navigate the file system to the required DatabaseViews.xml file. On selecting the file, the Open button is selected.

The database views are loaded into the Database Views Editor form, and a new option is available under the View Definition Set pull-down called Unnamed Definitions.

The user can copy Database View definitions from the Unnamed Definitions list to the User View list for use in the current project.

Set the View Definition Set to display the Unnamed Definitions by selecting the pull-down option. This will list all of the Unnamed Definitions in the Views tab grid.


66


On selecting the required definition, the Copy option is selected via the right-mouse context menu.

The View Definition Set is changed to display the User Views by selecting from the pull-down option. This will list all the User Views in the Views tab grid.

Anywhere within the Views tab grid, the right-mouse context menu may be accessed and the Paste option selected. The Definition is now available in the User Views list

To save the User Views, click the Save link on the View Definition Set toolbar. To unload the Unnamed Definitions from the Database Views Editor, set the View Definition Set pulldown option to Unnamed Definitions and click the Close link on the View Definitions Set toolbar. User Views are created and modified in the same way as Project Views.


67


7.4.2

View Properties tab

On this tab, the user enters the descriptive details of the Database View. The information entered is stored in the General and Basic definitions category fields of the DBVW as shown.

The information entered will help other users when they are searching for a view to use when they are working within the other PDMS modules, i.e. reporting. On this tab the user also selects the base Element types that the view will be based upon. These can be manually entered in the text box, or by selecting the (…) ellipsis button. The Select element types form will be shown. The Attribute filters and Expression filters pull-down sections allow the user to set the selection criteria of the selected Element types. When the user Adds or Deletes a filter they are actually creating and deleting ATTFIL and EXPFIL elements in the DBVW hierarchy. To add either an Attribute filter or Expression filter, select the Add Filter link within the appropriate pull-down section to create a new empty row within the appropriate section. The user then enters the expression, either by manually entering the values or using the pull-down lists that are available under the Attribute, Operator and Expression type columns. To delete a filter select the row with the expression to be deleted and then select the Delete Filter link.


68


7.4.3

Data Sources tab

On this tab the user defines the DBVW’s creation SRCELE elements and CRERUL elements.

To create a SRCELE element, select the level that the item is to be created at in the tree-view and via the right-click context menu select New SRCELEMENT.

Example of multiple SRCELE in a DBVW.

To delete a SRCELE element, select the SRCELE in the tree-view, and via the right-click context menu select Delete. If the selected SRCELE owns other SRCELEs then these will be deleted as well, along with any expressions or attributes that are local to it.

7.4.4

Columns tab

Here the user defines the columns of the view; each row in the grid is either an ATTCOL or EXPCOL. This tab has a toolbar of available options and selection settings:

The pull-down menu lists all of the available SRCELE’s that are defined in the current Database View, when a new row is added to the grid, the Data Source column is populated with the value that is selected in this list, and makes the new columns local to the selected SRCELE.


69


The New link button will create a new row within the grid. The new row is appended to the bottom of the grid. When a new row is created the user does not need to determine whether they are creating an ATTCOL or EXPCOL; the system will determine this when the user enters the data into the rows cells.



The system will change the DBVW hieratical element type automatically when a user changes the rows contents.

The Delete link button will delete the selected row(s) in the grid - to select multiple rows the Ctrl or Shift keys need to be depressed on selection using the left mouse button. The user can populate the grid with all of the selected view’s Element types standard attributes by selecting the Add Standard Attributes link button. The Add Status Column link button will add a row to the grid with the Attribute/Expression cell prepopulated with the Status Attribute. It will also navigate the cursor to the Qualifier cell for the user to select or manually type in the required value.



The Qualifier cell will only have a list of STADEF’s if the Data Source Element type has a STADEF with a matching Controllable Element.

The grid is a list of all the ATTCOL and EXPCOL columns that are required in the view of the Elements data. The user can select from the populated lists the attributes to use, or type the expressions in to the cells. The user is able to change the header text of the column in the Column Name column within the grid so that it is more descriptive to the end user. It is also common that duplicate named attribute columns occur when using SRCELE items, and this allows the administrator to define distinctive names.



As per all of the grids used within the plant suite, the columns can be resized by dragging the column headers, and sorted by clicking on the column headers

The grid allows the users to enter the Basic definition field values that are manually entered via the Current Element Editor.


70


The columns in the grid map to the following ATTCOL and EXPCOL element fields: Grid Column Name

ATTCOL Elements fields

EXPCOL Element fields

Data Source

DBVW or DBVW SRCELE’s

DBVW or DBVW SRCELE’s

Attribute/Expression

Attribute

Expression

Column Name

User-defined name

User-defined name

Description

Description

Description

Type

UDA type

Readonly

Read only

Expression Qualifier

7.4.5

Expression type Attribute Qualifier

Preview tab

This tab allows the user to see the resulting data that the database view will be populated with. However, due to the Lexicon module not having access to any other database except the Dictionary Databases, only views of dictionary data can be previewed within Lexicon. To preview the data in other modules, the user has to create a report based on the Project Database View and run said report.


71


7.5

Creating a Branch and Pipe Database View – A Worked Example

Using the Database Views Editor the user will create a Database View based on a Design BRANCH element. It will contain attributes that are local to the element and attributes from the owning PIPE. Exit PDMS and Re-Enter the Training project through the Lexicon module using the details provided by the Trainer, for example:

Project

Training

Username

-

SYSTEM

Password

-

XXXXXX

MDB

-

A-PIPING

Click the Login button.

If the Database Views Editor is not displayed, open it using the main menu option: Display > Database Views Editor.

7.5.1

Creating the DBVW

Create new a Database View by selecting the Views tab and, using the right-click context menu, select the option: New > View.

A new DBVWWL and DBVW are created in the Dictionary Explorer, plus an empty definition within the Database Views Editor form:


72


The DBVW is given a default Name in the Database Views Editor in the format of Table (where x is a sequential number that is allocated to each view). To give the DBVW some properties, select the View Properties tab. Enter the details for the User-defined name and Description: User-defined name:

Branch Details

Description:

Branch Details View

The View Properties tab should be updated as shown below; note that the Name of the view is now displayed in the list of Views and has been given the values entered into the User-defined name field.

The Database View now needs to be associated with one or more Element types. The user can either enter the Element types separated by spaces into the field or by clicking the (…) ellipsis button to display the Select element types form. Click the … button and from the list of Available element types select the BRANCH element and click OK to close the form. The Element types field will be populated with the elements selected on the form.


73


In this DBVW all of the items of the selected Element types will be returned to the view, therefore there is no requirement for any Filters. Because the DBVW was created in the Editor it only has a Userdefined name defined. If the user looks for the DBVW in the Dictionary Explorer it is named DBVW 1 beneath DBVWWL 1. Where there are a number of views, this will become a problematic administrative issue, so it is a good working practice at this stage to give the DBVWWL and the DBVW identifiable names. For the DBVW this is quite often the same name used as the User-defined name. Using the Dictionary Explorer navigate to DBVWWL 1.

In the Current Element Editor window, enter into the Name field: DBVWWL-TRAINING.

Using the Dictionary Explorer navigate to the DBVW 1. In the Current Element Editor window, enter into the Name field: Branch_Details_View.

7.5.2

Defining the Data Sources

Select the Data Sources tab in the View Detail section of the form. This will allow the user to see the current Data Source; there should only be one listed i.e. the Database View. The entry is listed with the Description text entered in the previous step.


74


In this worked example the view will not use any SRCELE, so all the settings on the tab will be left as the default values.

7.5.3

Defining the ATTCOL and EXPCOL columns

Next select the Columns tab in the View Detail section of the form to allow the user to add the required columns to the Database View.

7.5.3.1 Defining Standard Attributes and UDA’s (ATTCOL’s) On the Columns tabs toolbar, click the New link button to add an empty row to the grid.



The Data Source column will be populated with the default Data Source from the previous step

Next the user enters either an Attribute name or an Expression in PML / XPATH format into the Attribute/Expression column cell. The cell has a pull-down list, that when selected, will display an entire list of standard attribute and any UDA attributes for the selected Element type(s). If a PSEUDO attribute is required then its name has to be entered into the cell in the same way an expression would be.

From the pull-down list, select the NAME attribute. This will enter the text NAME into the cell; notice that the Description and Type have been automatically populated from the information from the Dictionary database for the NAME attribute.


75


On the Columns tabs toolbar, click the new link button to create another row, and from the pull-down list of attributes in the Attribute/Expression column select the attribute HBOR.

Add another row and set the Attribute/Expression column cell to the attribute HCON. Now add four more rows and set the Attribute/Expression columns cells to the attributes HREF, TBOR, TCON and TREF respectively. The grid should be as follows:

7.5.3.2 Defining Pseudo Attributes (ATTCOL’s) The next three attributes that are to be added to the view are Pseudo attributes; these are defined by manually entering the attribute names into the relevant columns cell. Add a new row and enter into the Attribute/Expression column cell the text CLLENGTH. Add two more rows and enter the following into the each of the rows Attribute/Expression column cell respectively:

Row 1:

TULENGTH

Row 2:

BRWEIGHT

The grid should be as follows:

At this point the user should perform a Save Work (Lexicon > Save Work).

7.5.3.3 Defining Expressions (EXPCOL’s) The next row in the view is to be an expression column; it will retrieve the Name of the Fluid that is associated with the Spec of the Branch.


76


Create a new row and enter the following expression NAMN OF FLUREF OF PSPEC into the Attribute/Expression cell in the row. Because an expression has been entered, the Description cell was not populated. So the end user knows what the column is returning a meaningful description should be added. Enter Fluid into the Description cell. The Type has been set to TEXT automatically; this is correct for the result of this expression as it will return a string value. However, sometimes this may not be automatically set correctly and will have to be changed to the relevant type. The Expression Syntax has been set to PML; once again the system attempts to set the correct value but may require user alteration.

Create six more rows with the following values: Data Source Branch Detail View Branch Detail View Branch Detail View Branch Detail View Branch Detail View Branch Detail View



Attribute / Expression NAMN OF PIPE :APPROVED OF PIPE :CHECKED OF PIPE :DESIGNED OF PIPE TEMP OF PIPE PRES OF PIPE

Description Pipe Pipe Approval Pipe Checked Pipe Designed Pipe Temperature Pipe Pressure

Type TEXT TEXT TEXT TEXT REAL REAL

Expression Syntax PML PML PML PML PML PML

These expressions are a mixture of standard attributes and the UDA’s created earlier in this training course.

The Columns grid should now be as follows:


77


Perform a Save Work at this point.

7.5.4

Testing the Database View

In order to check that the Database View is returning the correct information and because the Element type was set to a Design BRANCH, the view will only produce results within the Design module using a Report. To switch to the Design module, from the main toolbar select Lexicon > Modules > Design > Macro Files Click Yes when prompted to Leave Lexicon and enter Design? In the Design module, a pre-defined report is run by selecting from the main menu Utilities > Reporting > Designer… to open the Report Designer window.

 Refer to TM-1004 AVEVA Plant (12.1) Reporting for further information on Reporting methodologies.

From the main toolbar, select File > Open… to open the Open Report dialog.

Using the Look in option list on the Open Report dialog select the option


78


This will open the Browser For Folder dialog. Navigate to the folder: C:\AVEVA\Plant\Training12.1\Training\Reports Click OK to close the dialog.

Select the report TM-1308_Lexicon_Database-Views_WorkedExample1_Report from the list of Report Definitions and click the Open button to open the report. The report needs to be attached to the database view that has been created in the worked example. To do this, click the Data source button on the Report toolbar to display the Data Source Wizard. On the initial page of the wizard, select the Copy option then click Next > On the next page of the wizard, select the View with the Name Branch Details. This is the User-defined name that was entered when the Database View was created in Lexicon, click Next >

The user will be prompted with the following warning. Click the Yes button.

On the next page of the wizard click Finish. In the Field List tree-view expand the node called Branch Detail. The columns defined in the database view are listed here and the user can observe how the Name and Column Name values of the database view are used for distinguishing the field names that may be used within the report. Click the Run Report button on the main toolbar to run the report. Examine the resulting preview and check that the attribute data for Branches and Pipes is being returned. Close the Run Report preview window and the Report Designer window. Now the user must switch back to the Lexicon module. From the Design module main menu select Design > Modules > Lexicon… Click Yes when prompted to Leave Design and enter Lexicon?

Exercise 6 – Creating a Nozzle Database View Create a Database View for Equipment Nozzles. Provide the Database View with the following properties: Name:

Equipment_Nozzles

Description:

Equipment and Nozzles


www.aveva.com 79


User-defined name:

Equipment and Nozzles

Include the following attributes from the specified Design Element types Nozzle (NOZZ)

NAMN DESC CREF CATR P1 BORE P1 CONN POSITION IN SITE P1 DIR IN SITE TPRESS PRESS TEMP

Equipment (EQUI)

NAMN POSITION IN SITE :DESIGNED :CHECKED :APPROVED

Test the Database view using the pre-defined report TM-1308_Lexicon-Exercise 6, (located in the folder C:\AVEVA\Plant\Training12.1\Training\Reports).

7.6

Modifying the Branch and Pipe DBVW using SRCELE – A Worked Example

As discussed earlier, rather than creating expressions to navigate elements in the hierarchy to get to and retrieve data, the source element (SRCELE) can be used within the Database View to simplify navigation by making other elements the source of data within the Database View.


80


Using the Database Views Editor the user will create a copy of the previous Database View and use the SRCELE to replace the expressions that extract data from the PIPE and FLUI elements as source elements with the BRANCH element as the Base Element (Element type) of the database view.

7.6.1

Copying a Database View

If the Database Views Editor is not displayed, open it using the main menu option: Display > Database Views Editor. Within the View Definitions Set section, set the option to Project Views and select the Branch Details database view. Using the right-click context menu, select the option Copy, followed by Paste.



This has created a copy of the Database View created in the previous example.

Select the newly create Database View in the list and using the right-click context menu select the option Rename. In the selected textbox enter the name Branch Details 2.

Select the View Properties tab and set the User-defined name and the Description.

User-defined name:

Branch Detail 2

Description:

Branch Details with SRCELE View

Because the DBVW was copied in the Editor form it only has a User-defined name set - named CopyOf/Branch_Details_View. It is advisable, at this stage, to give the copied DBVW a distinguishable name Navigate to the DBVW in the Dictionary Explorer.


81


In the Current Element Editor window, enter Branch_Details_View_2 into the Name field.

7.6.1.1 Selection using single SRCELE Select the Data Sources tab and select the top item in the tree-view - DBVW Branch Details with SRCELE View. Using the right-click context menu, select the option New SRCELEMENT. This has created a Source Element under the database view, and made it the current element in the Database Views Editor tree-view. The SRCELE needs to have its properties set to determine the PDMS Element that is to be the source. In the Properties section, the Description describes the source element and an Expression in PML or XPATH defines the Source Element PDMS type. Description:

Owning Pipe

Expression:

PIPE

Expression type:

PML

The Data Source should now be as follows:

The next step is to modify the database views columns to use the PIPE source element. Select the Columns tab.



Now that there are two source element’s defined within the view, under the Data Source column, there is a pull-down menu that can be used to set the appropriate source element for the Attribute / Expression

In the current database view the following rows have been defined with expressions that navigate to the PIPE element to get the attribute values: 

NAMN OF PIPE



:APPROVED OF PIPE



:CHECKED OF PIPE



:DESIGNED OF PIPE



TEMP OF PIPE



PRES OF PIPE


www.aveva.com 82


Select the Data Source cell of the row that contains the expression NAMN OF PIPE and using the pulldown option change the Data Source from Branch Details with SRCELE View to Owning PIPE.

Due to the Source Element now being defined as the Owning PIPE, the Attribute/Expression cell of the row can now be replaced with the attribute. Replace the Attribute/Expression of NAMN OF PIPE by typing in the attribute NAMN as shown



Now that the cell is an Attribute, the Expression Syntax that was set to PML has been unset, and the Type cannot be changed as it is being set by the attributes database definition.

When the Database View columns are shown as fields in the Report Designer, the field will be listed by the Attribute’s name. This is because attributes are listed by their Name but, expressions are listed by the Description set in the Database View. To make a Data Source’s attribute distinguishable from the Base Element’s attribute in the Report Designer fields list, the User enters a text string into the Column Name cell within the Database View. To make the PIPE’s NAMN field easily recognisable, select the Column Name cell of the row and enter the text Pipe Name. The row should now be as follows:

The remaining PIPE expressions need to be modified in a similar way, as the NAMN expression that has just been changed. Repeat the previous steps so that the Database View looks like this:


83


7.6.1.2 Selection using Nested SRCELE’s The expression that selects the Name of the Fluid Reference of the Pipe Spec of the Branch, NAMN OF FLUREF OF PSPEC can be derived using Source Elements rather than via an Expression. Getting to the NAMN of the FLUREF from the BRANCH requires two navigational jumps across PDMS Elements. As shown below, the PSPEC points to a SPEC element that has a FLUREF attribute which, in turn points to a FLUI element that has a NAME attribute.

BRANCH

PSPEC

SPEC

FLUREF

FLUI

NAMN

Using nested SRCELE’s the same navigation and attribute can be retrieved. The following steps will take the user through the creation and definition of Nested SRCELE’s. Select the Data Sources tab and in the tree-view select the node named DBVW Branch Details with SRCELE View. Using the right-click context menu select the option New SRCELEMENT. A child SRCELE (Source Element) has been created under the tree-view. The SRCELE needs to have its properties set to determine the source PDMS Element. In the tree-view of the editor, ensure the newly created SRCELE is the CE and the Properties as shown: Description:

Branch Specification

Expression:

PSPEC

Expression type:

PML

The Data Sources tab should now be as follows:

Now make the SRCELE Branch Specification node in the tree-view the current selection and using the right-click context menu select the option New SRCELEMENT. This will create another SRCELE, but this time it is created under the previously created SRCELE. Making sure that the newly created SRCELE is the current element in the tree-view, set its Properties as shown: Description:

Specification Fluid / Medium

Expression:

FLUREF

Expression type:

PML


84


The Data Sources tab should now be as follows:

The next step is to modify the Database View column that navigates and returns the Fluid Name, to use the nested SRCELE source element. To achieve this, select the Columns tab in the editor to view the columns. Select the row that has the Attribute/Expression cell set to NAMN OF FLUREF OF PSPEC, and change the Data Source cell value to Specification Fluid / Medium from the pull-down list. Replace the Attribute/Expression cell value by entering the attribute name NAMN; as before, the Column Name should be changed to make the field easily recognisable. Enter Fluid Name into the cell. The final database views columns should now be defined as shown below:

The user performs a Save Work at this point.

7.6.2

Testing the Database View

In order to check that the Database View is returning the correct information and because the Element type was set to a Design BRANCH, the view will only produce results within the Design module using a Report. To switch to the Design module, from the main toolbar select Lexicon > Modules > Design > Macro Files Click Yes when prompted to Leave Lexicon and enter Design? In the Design module, a pre-defined report is run by selecting from the main menu Utilities > Reporting > Designer… to open the Report Designer window.  Refer to TM-1004 AVEVA Plant (12.1) Reporting for further information on Reporting methodologies.

Using the Look in option list on the Open Report dialog, select the option


85


This will open the Browser For Folder dialog. Navigate to the folder: C:\AVEVA\Plant\Training12.1\Training\Reports, Click the OK button to close the dialog.

Select the report TM-1308_Lexicon_Database-Views_WorkedExample2_Repor, from the list of Report Definitions and click the Open button. The report needs to be attached to the database view that has been created in the worked example. To do this, click the Data source button on the toolbar to display the Data Source Wizard. On the initial page of the wizard, select the Copy option and click Next >. On the next page of the wizard, select the View with the Name Branch Details 2, and click Next >.

The user will be prompted with the following warning. Click the Yes button.

On the next page of the wizard click Finish. In the Field List tree-view, expand the node called Branch Detail 2. The columns defined in the database view are listed here, and the user is able to see how the Name and Column Name values of the database view are used for distinguishing the field names used within the report. Click the Run Report button on the main toolbar to run the report. Examine the resulting report preview and check that the attribute data for Branches and Pipes is being returned. Close the Run Report preview window, and the Report Designer window. Now the user must switch back to the Lexicon module. From the Design module main menu select Design > Modules > Lexicon… Click Yes when prompted to Leave Design and enter Lexicon?


86


Exercise 7 – Modifying the Nozzle Database View Using the previous Chapter as a guide, complete the following tasks: 1. Modify the Database View created in Exercise 6, and replace the direct attribute associations with a SRCELE where appropriate. 2. Add a filter to the database view that returns only named nozzles. 3. Add a filter to return only the nozzles of Equipment in the Site /SITE-EQUIPMENT-AREA01. 4. Test the Database view using the pre-defined report TM-1308_Lexicon-Exercise 7, which can be found in the folder C:\AVEVA\Plant\Training12.1\Training\Reports


87


7.7

Using Database Views for Lexicon Administration – A Worked Example

In addition to using database views for the basis of reports, the administrator can also use them to help maintain the PDMS system. The views can be used to find unset values on elements, both in the Design and Drafting modules plus the administration modules. Using the Database Views Editor, the user creates a new database view that returns all the UDAs complete with the Reporter Text and their Descriptions. If the Database Views Editor is not displayed, open it using the main menu option: Display > Database Views Editor. Change the View Definition Set pull-down list to display the option User Views.

In the Views list, using the right-click context menu, select the option New > View to create an empty Database View. The DBVW is given a default Name in the Database Views Editor. Give the DBVW properties by selecting the View Properties tab, and in the view properties set the User-defined name, Description and Element types.

User-defined name

ALL RPTX and DESCR

Description

All Report Text and Description Text

Element types

UDA

The next step is to define the columns (attribute fields) to display in the database view. Select the Columns tab and create new rows. Enter the following in to the Attributes/Expressions cells of the rows: Row1

NAMN

Row2

OWNER

Row3

RPTX

Row4

DESC

Because the data being viewed is available within the Lexicon module, the user can select the Preview tab to see the resulting populated database view. The preview is shown on the following page.


88


To ensure the returned information is more selective, the user could apply an Attribute or Expression Filter to the database view definition. To make the view only return the User Defined Attributes that where created earlier in the training guide, select the View Properties tab Expand the Expression filters section and click the Add Filter link.


89


Within the Expression cell, enter the expression NAMN OF UWRL eq 'UWRL-PROJECT/DICT', and set the Expression type cell to PML

Return to the Preview tab and observe the change.


90


Exercise 8 – Create a DBVW that checks for UNSET Descriptions Create a database view that checks the Dictionary database elements for unset Descriptions on the following Element types: 

DBVW



DBVWGROUP



DBVWSET



SRCELEMENT



UDA



UDET



USDA


91

Lexicon Rev 1.0

Recommend Documents