• No results found

TM-3652 AVEVA Engineering (14.1) Engineering Administration Rev 2.0

N/A
N/A
Protected

Academic year: 2021

Share "TM-3652 AVEVA Engineering (14.1) Engineering Administration Rev 2.0"

Copied!
257
0
0

Loading.... (view fulltext now)

Full text

(1)

TRAINING GUIDE

www.aveva.com

AVEVA Engineering

(14.1)

Engineering Administration

TM-3652

(2)
(3)

3

www.aveva.com

© Copyright 1974 to current year.

Revision Log

Date Revision Description of Revision Author Reviewed Approved

28/05/2014 0.1 Issued for Review HU

30/05/2014 0.2 Reviewed HU / KI JB

09/06/2014 1.0 Approved for Training 14.1 HU / KI JB GC

18/06/2015 2.0 Approved for Training 14.1.SP1 HU / KI JB GC

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.

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

(4)

www.aveva.com

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.

Printed by AVEVA Solutions on 30 June 2015 © AVEVA Solutions and its subsidiaries 2001 – 2015

AVEVA Solutions Ltd, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom. The AVEVA Tags user interface is based on the Microsoft® Office FluentTM user interface.

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.

(5)

5

www.aveva.com

© Copyright 1974 to current year. 1 Introduction ... 9

1.1 Aim... 9

1.2 Objectives ... 9

1.3 Prerequisites ... 9

1.4 Course Structure ... 9

1.5 Using this guide ... 9

2 AVEVA Engineering Data Model ... 11

2.1 AVEVA Engineering Project Data Setup ... 14

Standard Project Setup ... 14

UDETs and UDAs Definition ... 14

Status Configuration ... 15

Datasheets and Revision Configuration ... 15

Flexible Explorer Setup ... 15

Inter-disciplinary Project Data ... 15

2.2 AVEVA Engineering Data model setup – Admin Module ... 16

2.3 AVEVA Engineering Data model setup – LEXICON Module ... 16

2.4 AVEVA Engineering Data model setup – Engineering Tags Application ... 17

Exercise 1 – Develop a Data Model Definition Using Flow Chart Diagram ... 18

3 Project Setup for AVEVA Engineering (Admin Module) ... 19

3.1 AVEVA Administration Modules ... 19

Admin ... 19

3.2 Creating a Project ... 19

3.3 Setting up a Project (Non Interdisciplinary Project Data) ... 21

Create Teams, Users and Engineering Databases – Worked Example ... 22

Exercise 2 – Creating Engineering Database and Distributed Hierarchy ... 32

3.4 Setting up a Project (Interdisciplinary Project Data) ... 33

3.5 Inter-disciplinary Project Setup Workflow ... 34

Create Discipline ... 34

Create Maturity ... 38

Create DB-Sets ... 41

Initiate Inter-disciplinary Project Data... 42

Update Inter-disciplinary Project Data... 48

Create Project Baselines ... 51

Create Users for Inter-disciplinary Project Data ... 55

Exercise 3 – Inter-disciplinary Project Data ... 58

4 Engineering Element Types and Attributes Definition (LEXICON Module) ... 61

4.1 Engineering Objects (UDETs) definition- A Worked Example ... 63

Creating a UDET world (UDETWL) ... 63

Creating a group (UDETGR) ... 64

Creating a UDET ... 64

4.2 General Attributes (User Defined Attributes: UDAs) - A Worked Example ... 66

Creating a UDA world (UWRL) ... 66

Creating a UDA group (UGRO) ... 66

Creating a UDA ... 67

Creating a referenced UDA ... 68

Graphical views of elements and attributes ... 69

4.3 Distributed Attributes- A Worked Example ... 70

Creating a Distributed UDET ... 71

4.4 Distributed Attributes Definition ... 73

Creating a Distributed Attributed Definition World (DSXWRL) ... 75

Creating a Distributed Attribute Definition Group (DSXGRP) ... 75

Creating a Default Home Definition (DSXHOM) ... 76

Creating a Default Home Destination Definition (DSXDST) ... 77

Creating a Distributed Attributes Schema (DSXSCH) ... 78

Creating a Binding Elements Definition (DSXOWN) ... 78

Creating a Bound Elements Definition (DSXMBR) ... 79

Viewing the Distributed attributes definition ... 80

(6)

www.aveva.com

4.5 Status Definitions- ... 81

Creating Status Reasons ... 81

Create Status Configuration world (STAWLD) ... 83

Create Status Definition (STADEF)... 83

Create Status Value (STAVAL) ... 84

Exercise 5 – Status Control ... 88

4.6 Database Views Definition ... 89

Database Views control ... 89

Database Views Setup ... 93

Create Database Views World (DBVWWLD) ... 93

Create Database Views Group (DBVWGR) ... 94

Database Views (DBVW) ... 94

Attribute Columns (ATTCOL) ... 95

Expression Column (EXPCOL) ... 96

Attribute Filter (ATTFIL) ... 96

Expression Filter (EXPFIL) ... 97

Create Rule (CRERULE) ... 98

Set Parameter (SETPAR) ... 99

Set Attribute (SETATT) ... 101

Set Status (SETSTA) ... 102

Source Element (SRCELE) ... 104

Preview created Database View list/table ... 106

Database View Set (DBVWSE) ... 106

Database View management ... 107

Exercise 6 ... 108

5 Interdisciplinary Project Data ... 109

5.1 Controlled Object Revisioning ... 110

Create Revision Configuration World (REVCWL) ... 110

Create Revision Configuration Group (REVCGP) ... 110

Create Revision Number Definition (REVNOD) ... 111

Create Revision Configuration (REVCON) ... 113

Version Control configuration (VERCON) ... 116

Exercise 7 ... 118

5.2 Shared Services System ... 119

Setting up a Notification Service Server ... 120

Notification Service Client ... 122

Notification Proxy Agent ... 123

5.3 Subscriptions ... 125

6 Datasheets ... 129

6.1 Datasheets Configuration Overview ... 129

Database Views Set for Datasheets – A Worked Example ... 130

Create Datasheets Template Records – A Worked Example ... 132

Adding Border to Datasheet Templates ... 138

Reference Existing Datasheet Template Excel File ... 140

Reference Existing Datasheet Template Excel File – A Worked Example ... 141

Database Attribute Mapping to Datasheet Template – A Worked Example ... 143

Auto Database Attribute Mapping to Datasheet Template ... 145

Auto Database Attribute Mapping to Datasheet Template – A Worked Example ... 146

Units of Measure Definitions – Unit Sets ... 148

Unit Sets Definition for Datasheet and List columns – A Worked Example ... 149

Assigning Default Unit of Measure to Datasheet Cell – A Worked Example ... 150

Assigning Unit Sets to Datasheet – A Worked Example... 153

6.2 Using Standard Controls Operations in Datasheet Template Cells ... 155

Mapping Checkbox to Datasheet Template Cells – A Worked Example ... 155

Mapping Radio Buttons to Datasheet Template Cells – A Worked Example ... 157

Mapping Picture Box to Datasheet Template Cells – A Worked Example ... 158

Mapping Free Text Cell to Datasheet Template Cells – A Worked Example ... 162

Mapping Page Info to Datasheet Template Cells – A Worked Example ... 163

Mapping Process Cases to Datasheet Template Cells – A Worked Example ... 164

Mapping Case Control to Datasheet Template Cells - A Worked Example... 165

6.3 Mapping Continuation Area to Datasheet Template ... 166

(7)

7

www.aveva.com

© Copyright 1974 to current year. Mapping Continuation Area to Sublist – A Worked Example ... 169

6.4 Mapping Symbols to Datasheet Template ... 171

6.5 Mapping Symbols to Datasheet Template - A Worked Example ... 171

6.6 Adding Sketch Control to Datasheet Template ... 172

Adding Sketch Control to Datasheet Template – A Worked Example ... 172

6.7 Adding Note Page Control to Datasheet Template ... 176

Adding Note Page Control to Datasheet Template – A Worked Example ... 176

Datasheet Revision Control Configuration ... 177

Datasheet Revision Control Configuration- A Worked Example ... 177

Mapping Revision Block and Mark to Datasheet Template ... 187

Revision Block and Mark Mapping to Datasheet Template – A Worked Example ... 188

Exercise 8 – Datasheet Configuration ... 190

7 Project Explorer Configuration ... 193

7.1 Configuring the Flexible Explorer - A Worked Example ... 194

Creating a PBS world (PBSWLD) ... 195

Creating a PBS template (PBSTPL) ... 195

Creating a PBS Object (PBSOBN)... 197

Creating a PBS Text Node (PBSTXN) ... 198

Creating a PBS criteria Node (PBSCRT) ... 204

Element Member items ... 205

Grouping elements by class (Attributes) ... 206

7.2 Document Template for the Flexible Explorer - A Worked Example ... 210

Creating an Object Node for Datasheets ... 210

Creating an Object Node for Diagrams ... 212

Creating an Object Node for Engineering Lists ... 214

Exercise 9 ... 216

8 Database Views Editor ... 217

8.1 Sample DB Views and View set ... 219

8.2 Defining a Database View ... 220

Defining a Database View – Single Sourced Data ... 221

Defining a Database View – Multiple Sourced Data ... 225

Defining a ‘View Set’ ... 232

Exercise 10 ... 235

9 AutoNaming Engineering items ... 237

9.1 The AutoNaming Feature ... 237

9.2 AutoNaming Configuration setup ... 238

Single AutoNaming rule for all Engineering items (ENGITEs) ... 239

AutoNames based on expressions ... 243

9.3 AutoNaming conditions ... 247

9.4 AutoNaming Examples ... 247

Exercise 11 ... 250

Exercise 13 ... 251

1 Appendix A ... 253

1.1 New Syntax for Distributed Attributes ... 253

2 Appendix B ... 254

2.1 Distributed Attribute and Attribute Syntax ... 254

3 Appendix C ... 255

(8)
(9)

9

www.aveva.com

© Copyright 1974 to current year.

1 Introduction

This training guide has been developed for the engineering project administrative user who will be responsible for the creation, configurations and maintenance of a defined project data infrastructure (data model). The sections covered within, attempts to detail and describe all relevant steps required for structuring an engineering data model.

1.1 Aim

This guide aims to be a source of the administrative knowledge necessary for the administration of an AVEVA Engineering project. This includes the complete definition, setup and configuration of an appropriate engineering data structure which will be run within the AVEVA Engineering Tags module. The contents of this guide can also be referenced during maintenance activities.

1.2 Objectives

Within this guide, the following will be covered:

- Definition of a standard AVEVA Engineering data model

- Descriptions of the standard creation of project users, teams, databases and multiple databases (MDBs)

- Descriptions of the setup of an ‘Interdisciplinary Project Data’ model

- Detailed descriptions of the creation and setup of required elements within the LEXICON module - Data model setup via imported Excel files

- Example case studies and scenarios

- Configuration and setup of the user workspaces within the Engineering Tags application

1.3 Prerequisites

Trainees should be familiar with the use of LEXICON and Admin modules of AVEVA PDMS / Outfitting / E3D or AVEVA Administration products. Knowledge on the use and manipulation of the AVEVA Engineering Tags application is essential.

1.4 Course Structure

Training will consist of oral and visual presentations, demonstrations and set exercises. Each trainee’s workstation will have a supplied training project in which the sections in this guide are based upon, and will be 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, here is a summary; Menu pull downs and button press actions are indicated by bold dark turquoise text.

Information the user has to key-in will be red and in bold Italics.

Annotation for trainees benefit:

Additional information

Refer to other documentation

System prompts should be bold and italic in inverted commas i.e. 'Choose function' Example files or inputs will be in the courier new font, colours and styles used as before.

(10)
(11)

11

www.aveva.com

© Copyright 1974 to current year.

2 AVEVA Engineering Data Model

AVEVA Engineering is a data model management and visualisation application with which tagged items can be created, managed and stored, whilst maintaining a firm integration with corresponding or referenced 3D, Schematic and/or Engineering items.

An AVEVA Engineering data model could be structured to cater to a wide variety of engineering workflows and scenarios as required by the users or the engineering tasks being run. Typical AVEVA Engineering data models could be for (but not limited to…):

 The creation and/or management of tagged or engineering items (Data source)  Data integration center between several sources (data hub)

 Data visualisation

 Multi user and Multi discipline working environment  Inter discipline project data

 Generation of standard engineering data deliverables

Engineering data models are dependent on a project requirement, and are defined by the project applications implementation stakeholders.

An AVEVA Engineering data model is setup and configured by an Administrator, using the modules of the AVEVA Administration product as well as configuration tools within the AVEVA Engineering application. This training guide covers the administrative requirements for a standard AVEVA Engineering data model setup and configuration for a multi user and multi discipline project. It details the steps required for the creation, configuration and allocation of databases, engineering elements, attributes, datasheet templates and object revisioning.

A standard AVEVA Engineering data model could be based around the sample figure shown:

In the case shown, an Engineering object (which could be a tagged item) could have a collection(s) of its attributes assigned and grouped according to a nominated discipline. These attributes are known as ‘Distributed Attributes’.

(12)

www.aveva.com

The standard engineering data model could further be represented by the figure shown:

Engineering objects, along with their generic attributes and nominated distributed attributes can be displayed on a configured engineering list complete with attribute or expression columns. The acess rights of certain attributes can be restricted for specific project discipline users, but also allowing for concurrent independent creation / modification of permitted attribute values.

Each configured list is based on a ‘Database View’, which could also be utilized for the generation of ‘Reports’, Datasheet configurations and data subscriptions.

A schematic breakdown of a standard data model definition with its required procedures is displayed below:

(13)

13

www.aveva.com

© Copyright 1974 to current year.

For the definition of a more complex engineering data model (Setup for an Interdisciplinary Project data/ Controlled Object Revisioning (COR) ), the required procedures could be structured as shown:

(14)

www.aveva.com

The procedures shown are implemented within the Admin and LEXICON modules of the AVEVA

Administration product.

These procedures also allows for the setup of more complex AVEVA Engineering data models, which could be structured to provide a controlled revisioning of engineering objects across multiple database layers. This can also support the data subscription and notification mechanism, in which information is shared and consumed across disciplines.

Further setup and configuration carried out within the Engineering Tags application itself and utilise

embedded controls and functions which are reserved for an Administrative user only. These are summarized below, and will be covered in details later in this guide.

The AVEVA Administration 1.2 (or later) product will need to have been separately installed prior to commencing this training course

2.1

AVEVA Engineering Project Data Setup

Project set-up for use of AVEVA Engineering can be carried out in two main ways. The selection of a project creation method by the System Administrator is usually dependent on the project requirements. These methods are:

Project Data Setup for Non Inter-disciplinary (Standard Project Setup)

Project Data Setup for Inter-disciplinary

Both project data setup methods can be deployed on the same project

Standard Project Setup

The Standard Project Setup is used to for setting up new project, defining users’ access to a selection of existing or newly created databases for use of the AVEVA Engineering- Tags application.

The Standard Project Setup allows an administrator to create/modify various administrative elements such as Teams, Users, Databases, and MDBs etc. The element to be created/ modified via the Elements option gadget as shown below:

UDETs and UDAs Definition

To set up a data model definition for use in the AVEVA Engineering Tags Module, involves a number of procedures.

The LEXICON Module enables the definition of User Definable Attributes (UDA) that may be assigned to Engineering elements or objects.

User Defined Element Types (UDET) defined and configured as to represent the main engineering objects in project.

Distributed Attributes Schema, which defines the structural relationship between distributed attributes group and their associated element types. Also Database Views for use with Engineering List definitions and Datasheets.

(15)

15

www.aveva.com

© Copyright 1974 to current year.

Status Configuration

Status Control provides the ability to control and report on the status of individual model objects (e.g. Engineering UDETs) as they progress their lifecycles. It can be applied to any model objects, for example engineering tagged items, Diagrams etc. This section describes how to assign status definitions to engineering elements UDETs.

Datasheets and Revision Configuration

This section will give a basic overview on the definition of Objects Revision and Datasheet templates in AVEVA LEXICON Module to the deliver data entry and modification

functionalities within datasheets in AVEVA Engineering Tags.

Flexible Explorer Setup

Flexible Explorer provides the capability to present database content depending on user needs. This section is an overview on how flexible/Project Explorers are defined using sample scenarios, within the AVEVA LEXICON module.

Inter-disciplinary Project Data

Inter-disciplinary Project Data Setup is an added feature to the Admin Module to support the creation and configuration of Teams, complex Extract hierarchies, and MDBs for AVEVA Engineering projects utilising the Engineering Controlled Object Revisioning features and Notification mechanism with which data changes are sent as notifications to subscribing users

The Project Setup workflow for Inter-disciplinary Project has been designed allowing users to configure key Administration objects that are used to automate project setup, creating Teams, Databases (which includes only “Engineering” databases) and MDBs.

New Administration Data objects, Discipline and Maturity, have been introduced alongside the existing objects to configure Inter-disciplinary Project Setup.

Project setup automation is also implemented in PML which allows companies to tailor the process if they wish. Inter-disciplinary Project Setup Workflow is defined as:

Discipline: Discipline object can represent standard engineering Discipline as required

Maturity: Defines an Approval process that items could go through within their lifecycle. This could also be seen as tier areas. A sample approval process could be: Issued -> Approved -> Working, and requires 3 levels of extracts.

(16)

www.aveva.com

2.2

AVEVA Engineering Data model setup – Admin Module

AVEVA Engineering 14.1 is administered with the Admin and LEXICON Modules of the AVEVA Administration product.

Within the Admin module for a standard project, the following entities can be created and configured as required:

- Users - Teams

- Databases (ENGI DB) - Multiple Databases (MDBs)

This also incorporates the setup and application of the usual Admin controls for Data Access Controls (DACs), Global etc...

For the support of object revisioning, subscription and notification functions, the Admin module can also be used to setup and configure a slightly complex but relevant data model and database structure. This is covered in detail later in the guide.

2.3

AVEVA Engineering Data model setup – LEXICON Module

The LEXICON module reads and writes to a dictionary database. The framework and usability of an engineering data model is setup within the LEXICON module.

For a standard project, the following entities can be created and configured as required: - User Defined Element Types (UDETs)

- User Defined Attributes (UDAs)

- Definition of Distributed attributes and their owners - Status Definitions

- Database Views - Datasheet templates

- Revision configurations for both datasheets and controlled objects - Flexible Explorer Definitions

(17)

17

www.aveva.com

© Copyright 1974 to current year.

2.4

AVEVA Engineering Data model setup – Engineering Tags Application

AVEVA Engineering Tags application is essentially ready to be deployed after the conclusion of an initial data model setup and configuration within the Admin and LEXICON modules.

In order for the users to begin any actual work or data visualisations, the administrator will have to setup required database item locations, lists, integration configurations, default datasheet templates etc. This activity is dependent on the project / user tasks requirements.

(18)

www.aveva.com

Within the AVEVA Engineering Tags application, certain configuration functions are required for the

configuration of the user environment and work space. These functions are made available only for an administrative user, and include the configurations for:

- Database Views Editor - Categories and Lists - AutoNaming - Compare/Update - Datasheets

- Database locations for engineering items

The configurations of these functions are covered later in this guide.

In summary, the following chapters will cover:

Ideally a clean (new) project will be required in order to follow the demonstration described in the guide. Although any existing project can be utilised as appropriate

A copy of the demo project (ACE) containing a pre-configured and setup engineering elements will be supplied to act as a reference material and aid the trainee with working through the chapters in the guide

Macro files which could be used to create pre-configured dictionary elements will also be supplied

Exercise 1 – Develop a Data Model Definition Using Flow Chart Diagram

Develop the layout for a standard engineering data model for Lines, Equipment, Nozzles and Valves. List generic attributes for each of the engineering objects (tagged items). Also list and group list distributed attributes according to an appropriate discipline.

(19)

19

www.aveva.com

© Copyright 1974 to current year.

3 Project Setup for AVEVA Engineering (Admin Module)

3.1

AVEVA Administration Modules

As described previously, the AVEVA Administration product consists of 2 modules, Admin and LEXICON, which are explained in subsequent sections of this guide.

AVEVA Administration

Admin Project and User administration.

LEXICON Creation of User Defined Attributes, User Defined Element Types, Status Definitions, Revision Definition, Flexible Explorer Definition and Database Views.

Admin

The Admin module of the AVEVA Administration product administers the AVEVA Engineering and Everything3D products. Its main features include:

 Set up new projects, controlling which users have access to which databases.  Administer projects, including change management and setting AVEVA fonts.  Control user access to modules.

 Check data integrity.

 Reconfigure databases when necessary.

3.2

Creating a Project

Create a new project using the Project Creation Wizard 1.2.0 from the start menu select:

Start > All Programs > AVEVA > Manage > Project Creation Wizard 1.2.0

Enter the following details for the project. Project Training

Code TRA

Location: C:\Users\Public\Documents\AVEVA\Administration\Projects1.2.0\Training

Click the Create… button.

Login to the Admin module (AVEVA Administration) of the newly created project using the details provided

(20)

www.aveva.com

The choice of the project name is up to the trainee. A new or an existing project are both suitable for the

demonstrations contained within this guide

Project – Training Username – SYSTEM Password – XXXXXX Click the Admin tile.

It is not necessary to specify an MDB to enter Admin. Free Users, like

SYSTEM, are not

displayed on the Username pull down.

The Admin default screen layout will be displayed comprising of the main pull down menus, the Admin Explorer and the Admin functions form.

(21)

21

www.aveva.com

© Copyright 1974 to current year.

3.3

Setting up a Project (Non Interdisciplinary Project Data)

As described earlier, to set up a data model definition for use in AVEVA Engineering Tags Module, involves a number of procedures. One of the first steps is to create the required Engineering Databases, Teams and Users this is explained in the following section.

In the data model definition example displayed below, an engineering item ‘Pump’ (with associated ‘Motor’) consists of Mechanical, Electrical and Process attributes groups, whose data will be distributed across three (3) separate engineering databases.

Using team access control, each discipline will have full control of their own data whilst working with data issued from all the other disciplines.

This section will utilise an example scenario (which consists of engineering elements (Pump & associated Motor), and its Mechanical attributes data attached directly onto the engineering items. These attributes data will be stored within the Mechanical Engineering database.The Process and Electrical attribute data are distributed across two (2) separate Process and Electrical databases respectively. This will allow three (3) different teams to modify data on the engineering element concurrently.

The creation of teams, databases and MDB’s will be demonstrated using this sample engineering structure displayed below:

The following example demonstration will be conducted on the newly created ‘ACE’ project, or could also be accomplished on any existing project of choice

(22)

www.aveva.com

Create Teams, Users and Engineering Databases – Worked Example

To control who can modify or update engineering items (Pump & Motor) attribute data and distributed data, the following elements must be created in the AVEVA Admin Module according to the data model definition diagram shown previously.

Enter AVEVA Administration by selecting:

Start > All Programs > AVEVA >Manage > AVEVA Administration 1.2.0

Project – ACE

Username – SYSTEM Password – XXXXXX Click the Admin tile.

 Create three (3) separate “Teams” as shown. Teams

- AMECHENG

- AELECENG

(23)

23

www.aveva.com

© Copyright 1974 to current year.

(24)

www.aveva.com

USERS PASSWORD ELEC.ENGINEER A

MECH. ENGINEER A PROC. ENGINEER A

Make the Users members of the following teams: TEAM AELECENG TEAM MEMBER ELEC.ENGINEER

TEAM………AMECHENG TEAM MEMBER MECH.ENGINEER

(25)

25

www.aveva.com

© Copyright 1974 to current year.

TEAM ………..APROCHENG TEAM MEMBER PROC.ENGINEER

For further details, on creation of Teams and Users, please refer to AVEVA Plant System Administration User Guide (TM1300)

(26)

www.aveva.com

Create the following - three (3) different Engineering databases as shown:

1. Create Mechanical Engineering Database – To store Engineering Attribute Data that is directly attached to engineering Item in this case “Pump & associated Motor”.

To create Engineering database, select Databases & Extracts from the Elements options list. Click the Create button to display the Databases & Extracts form

Click the Master DB radio button and click the OK button to display the Create Database form.

Select <Team> AMECHENG from the Owning Team grid Name column.

Enter or select the following data:

Name TAGSMATER.

Description Mechanical Items (Tagnames-ENGWLD) Database Type Engineering

(27)

27

www.aveva.com

© Copyright 1974 to current year.

To create an Engineering World for Mechanical Attributes data in AVEVA Tags ‘database Explorer’, Select “Engineering Data World” from Element Type pull-down.

The “Create ENGWLD” (Engineering World) field is then displayed. Enter the required value in this case MECH-Items-and-AttData.

Engineering World (ENGWLD) is a top–level administrative container for engineering elements with ‘non distributed’ attributes data

(28)

www.aveva.com

2. Electrical Engineering Database - Storage for Distributed Electrical Attributes Data.

To create Engineering database for Distributed Electrical Attributes Data, select Databases & Extracts from the Elements options list. Click the Create button to display the Databases & Extracts form.

Click the Master DB radio button and click the OK button to display the Create Database form.

Select <Team> AELECENG from the Owning Team grid Name column. Enter or select the following data:

Name ENGIELECTDIST

Description Distributed Electrical Attribute Data Database Type Engineering

(29)

29

www.aveva.com

© Copyright 1974 to current year.

To create Distributed attribute data World (top-level administrative element) for Electrical Attribute data in AVEVA Tags database Explorer, select “Extended Properties World” from Element Type pull-down list.

The “Create XPIWLD” (Distributed World) field is then displayed. Enter the required value e.g. ELECTAttData as highlighted.

Distributed attributes World (XPIWLD) is a top–level administrative container for distributed attribute data.

Click the Apply button to create the database

(30)

www.aveva.com

3. Process Engineering Database - Storage for Distributed Process Attributes Data.

Repeat the procedure as described in step 2 (Electrical Engineering Database) to create Engineering database for Distributed Process Attributes Data.

To create Distributed attribute data World (top-level administrative element) for Process Attribute Data in AVEVA Tags database Explorer, select “Extended Properties World” from Element Type pull-down list. The “Create XPIWLD” (Distributed World) field is then displayed, enter the desired value in this case PROCAttData as highlighted.

The newly created Engineering databases must be added to the current project Multiple Database (MDB), in this case “A-Tags” MDB.

For further configuration and definition of an engineering project within the LEXICON Module, a writable Dictionary (DICT) Database must be created. This will store all the elements set up within the

LEXICON Module

Created a new Dictionary (DICT) Database named: ‘ENGDICT-B’, owned by the team ‘PPROJECT’ created. This will store all the elements set up within the LEXICON Module

(31)

31

www.aveva.com

© Copyright 1974 to current year.

To view the newly created Engineering Data World (ENGWLD) and Distributed World (XPIWLD) in AVEVA Engineering Tags database Explorer:

Log into AVEVA Engineering Tags Module

Project – ACE

Username – SYSTEM Password – XXXXXX MDB ---A-Tags Click the Tags tile.

(32)

www.aveva.com

Exercise 2 – Creating Engineering Database and Distributed Hierarchy

Using the data model definition developed in exercise 1, Login into AVEVA Admin Module using the details provided by the Trainer.

3 (a). Create the following Teams

- Process Team.

- Piping Material Team.

- Piping Stress Team. 3 (b). Create the following users

- Process Users.

- Piping Material Users.

- Piping Stress Users.

3 (c). Create the following databases

- Process Engineering Database – To store Engineering Element Attribute Data that is directly attached to engineering Item in this case “LineTags”.

- Piping Material Engineering Database - Storage for Distributed Piping Material Attribute Data.

- Piping Stress Engineering Database - Storage for Distributed Piping Stress Attribute Data.

Modify project MDB ( A-Tags) to include newly created Databases. Place the databases in the following order, Process Engineering Database (as the first Engineering DB in the Current Database grid), followed by Piping Material Engineering DB and Piping Stress Engineering DB.

3 (d). Login into AVEVA Engineering Tags Module using the details provided by the Trainer, to view the newly created Engineering Data World (ENGWLD) and Distributed World (XPIWLD) in AVEVA Tags database Explorer.

Project – ACE

Username – SYSTEM Password – XXXXXX MDB ---A-Tags Click the Tags tile.

(33)

33

www.aveva.com

© Copyright 1974 to current year.

3.4

Setting up a Project (Interdisciplinary Project Data)

Inter-disciplinary Project Setup allows engineering projects to be configured to support Controlled Object Revisioning functions in AVEVA Engineering.

Controlled Object Revisioning (COR) enables independent and concurrent working between disciplines and allows Engineers to be in control of the data they are consuming from other disciplines. When objects are released via status control a notification is sent to any users who subscribe to that object. The user, once notified, can choose if and when to adopt that change.

This process is implemented using AVEVA’s Database Extract functionality that allows Users to change data belonging to their own discipline, and to choose when to accept data changes from other disciplines.

An extract hierarchy is used to support the general Working -> Approval -> Issue mechanism for the data being modified. Extract databases called consumer extracts allow users to pull changes from other disciplines into their view

In the example diagram below the User is a Junior Piper working in the Piping Discipline. The Junior Piper has an Equipment list with their own discipline attributes (E, F, G), but also wants to see attributes from Instrumentation, Electrical and Mechanical disciplines. The Junior Piper can change the (EFG) data, but only has read access to other data via consumer extracts. The Junior Piper MDB has read-only access to consumer extracts for Instrumentation, Electrical and Mechanical disciplines.

Status Management functions are used to promote data from Working to Approval, and finally from 'Approval to Issued in the items normal lifecycle. Upon reaching the Issued level the system sends a notification to Users in other disciplines to indicate that changes are available once changes to data from one of the Instrumentation, Electrical or Mechanical disciplines has been made available in the Issued level.

(34)

www.aveva.com

3.5

Inter-disciplinary Project Setup Workflow

To simplify Inter-disciplinary Project Setup a workflow has been designed allowing users to configure key Administrative objects that are used to automate project setup, creating Teams, Databases and MDBs. Inter-disciplinary Project Setup Workflow is defined as:

As part of the Inter-disciplinary Project Setup Workflow, “Baseline” Project Data” can also be created. Baselines allow a view of all disciplines data to be saved in a particular state. Each discipline can continue to change data and create new revisions of data without changing the view of a project saved in a baseline. Baselines may be created at any time in a project after the initial project configuration has been defined, and in practice they are likely to be created at key project milestones.

Discipline data is not changed in a Baseline view, so Baselines do not have their own database hierarchy. Baselines have consumer extracts which are added to each disciplines released (master) database.

Through these consumer extracts System Engineers can control what version of released data will be saved to a baseline. Each Baseline has an MDB which contains all consumer extracts related to that Baseline. System Engineers use this MDB to view a Baseline.

Create Discipline

The first stage is to create disciplines.

Discipline objects have been introduced alongside the existing objects to configure Inter-disciplinary Project Setup. The object represents a Discipline as defined by the Engineering requirement.

In the Admin module, click Disciplines (ENG) on the Administration Elements form element type selector to display the Discipline elements form.

(35)

35

www.aveva.com

© Copyright 1974 to current year.

(36)

www.aveva.com

In the Create Discipline form, enter the following data:

Name: ELECTRICAL

The “Name”. Text field is used to define “Element” Name and can be modified any time before or after a project definition has been created

Display Name: Electrical

The “Display Name”.Text field is a descriptive text for the discipline and can be modified any time before or after a project definition has been created

Code (Required): ELEC

The “Code”.is alphanumeric Text field. The Code can be used within automatically generated teams, databases and MDB names

The “Code” must be unique for each discipline. Once an Inter-disciplinary project setup has been created discipline code cannot be modified. The Code can be modified until it has been referenced by a Project Definition

The Code must not contain symbols or spaces or Slashes (/). When discipline code is used in team names it must consist of alphabetic characters only

Description: Electrical

The “Description” Text field is the description of the discipline and can be modified any time before or after a project definition has been created

DB Range Start 250602

The “DB Range Start” Numeric field is used to set the lowest database number that will be applied to databases created for this discipline. The system finds the first unused DB number greater than or equal to the given number for databases created for this discipline

The DB number can be set to any valid DB number even if it is already in use or is shared by other disciplines. A warning is issued if the user selects a database number in the range that we have claimed for databases in AVEVA standard projects. (7000 to 8000 and 250000 to 255000). This does not prevent users from using a number in this range

(37)

37

www.aveva.com

© Copyright 1974 to current year.

Click the OK button to create the discipline and close the form.

Click the “Apply” button. Create the Discipline and initialise the form ready to create another new Discipline

The “Cancel” button. Close the form without creating the Discipline

The Discipline elements can only be deleted if they have not been used in a Project Definition. Discipline elements cannot be deleted at a satellite end of a globalised project

Repeat the procedure as described in “Section 3.5.1” to create the following disciplines using the information in the table below:

Discipline Display Name

Code Description DB Rang Start

(38)

www.aveva.com

Create Maturity

The next stage is to define the maturity levels.

Maturity defines the Approval process that items should go through in their lifecycle. A standard three level approval mechanism for example of Release-> Approve -> Work requires 3 levels of extracts:

Released = Master Approve = Level 1 Extract Work = Level 2 Extract.

Items can be created and modified in the “Work” 2nd level extract. Once they require Approval they are dynamically issued into the “Approve” 1st level extract after a status change. Then finally when they are APPROVED, they are dynamically issued into the Released Master database.

A Maturity hierarchy can have two or more extract levels, and the names used for each level can be defined during the creation of the Maturity objects.

To define a Maturity, click Maturity (ENGI) on the Administration Elements form type selector to display the Maturity elements form.

(39)

39

www.aveva.com

© Copyright 1974 to current year.

Click the Create button to display the Maturity form.

The Create and Modify functions display the same form which allows for new Maturity elements to be created and existing Maturity element attributes to be modified.

(40)

www.aveva.com

The arrows on the right side of the form is used to re-order the Maturity Objects. It is possible to create

Maturity objects in any order, and then re-order the levels to a preferred order. Maturity elements cannot be re-ordered once a project definition is created and they cannot be modified at a satellite of a Globalised project

Then enter the following data:

Name: RELEASED

The “Name”. Text field is used to define “Element” Name and can be modified any time before or after a project definition has been created.

The “Name” can be entered with or without the preceding ‘/’. Spaces are removed from names before submitting changes to the database.

Display Name: Released

The “Display Name”. Text field is a descriptive text for discipline and can be modified at any time before or after a project definition has been created.

Code (Required): RLSD

The “Code”.is an alphanumeric Text field. The Code can be used in automatically generated teams, databases and MDB names.

(41)

41

www.aveva.com

© Copyright 1974 to current year.

The Maturity Code must be unique for each maturity levels. Once an Inter-disciplinary project setup has been created

The Maturity Code cannot be modified. The Code can be modified until it has been referenced by a project definition

Description: MATURITY RELEASED

The “Description”. Text field is a description of the maturity level and can be modified at any time before or after a project definition has been created.

Repeat the same procedure as described in “Section 3.5.2” to create the following Maturity levels using the information in the table below:

Name Display

Name

Code Description

APPROVE Approve APRV MATURITY APPROVE

WORK Work WORK MATURITY WORK

Create DB-Sets

The automated Inter-disciplinary Project Setup mechanism creates Engineering databases and extracts. Relevant databases (e.g. Dictionary, Design etc.) which are not created during this process will need to be included in utilised MDBs in order for the users to gain access to relevant data from other applications. It is possible to create a DB Set to hold these relevant databases which will be referenced during Inter-disciplinary Project Setup creation using existing Administration DB Set functions as shown:

(42)

www.aveva.com

The created Dictionary (DICT) Database (ENGDICT-B) must be included in the created DBSET as this

will store all the elements set up within the LEXICON Module as well as grant access to the elements to engineering users who have the DICT DB included in their MDBs

Initiate Inter-disciplinary Project Data

To simplify the Inter-disciplinary Project Setup workflow an automation process has been designed allowing users to, create Teams, Databases and MDBs. When the automation process is run, an extract hierarchy is created for each discipline according to the specified maturity levels, along with consumer extracts for each Discipline extract hierarchy other than itself.

The Consumer extracts all belong to a single consumer extract team named <base-name>CX. No users need to be assigned to this team, they allow for the reference of other disciplines data

Before running the automation process for Inter-disciplinary Project Setup workflow. It is very important to review the Maturity levels definitions and other relevant setup necessary for the Inter-disciplinary Project Setup automation process to run

To run the Inter-disciplinary Project Setup, select

(43)

43

www.aveva.com

© Copyright 1974 to current year.

The Inter-disciplinary Project Data form is then displayed with pre-populated Disciplines and Maturity definitions.

In the Inter-disciplinary Project Data form, enter the following data: Base Name: ACE

The Base name is used to identify the project definition. It is used in naming conventions for databases and MDBs linked to this project definition. The Base name cannot be changed after project data has been created

(44)

www.aveva.com

To select the Database Set that contains databases

common to each discipline to be added to every Project Definition MDB.

Click the “Select” button from the COMMON DATABASE section of the Inter-disciplinary Project Data form to display the Select Common DB Set form.

In the Select Common DB Set form, select the preferred DB Set (e.g. Common Database Set) and click the OK button to update the Inter-disciplinary Project Data form and close the form.

(45)

45

www.aveva.com

© Copyright 1974 to current year.

The Naming Convention section of the Inter-disciplinary Project Data form is for information only. This shows how team, database and MDB names are formed.

Click the Create Project Data button to create teams and databases.

After Inter-disciplinary Project Data has created all the required database elements. The discipline list shows a green tick for each discipline that has been defined.

The Date and Time highlighted below is the date that the session in which the project definition was created is saved to the database.

(46)

www.aveva.com

A Project Definition can be deleted if no data has been stored in any of the databases. In a Globalised

project databases can only be deleted at the hub, and only if these databases are not allocated to another location.

Any error messages will be displayed in the Summary panel.

If project data is created some messages appear in the Summary panel along with a Details button which is a link to a log file that records the objects created, along with any warning messages.

(47)

47

www.aveva.com

© Copyright 1974 to current year.

When the Inter-disciplinary Project Data definition is run, a team is created for each combination of discipline and maturity. And a Team is created for all the consumer extracts.

(48)

www.aveva.com

Also when Inter-disciplinary Project Data project definition is run Master Engineering Databases are created for each Discipline and Database extracts for the main Maturity workflow and for the read only consumer extracts.

In the Databases & Extracts form apply a filter on the “TYPE” column to display the newly created ENGI database as shown above.

MDBs are created for each combination of discipline and maturity.

Update Inter-disciplinary Project Data

A new discipline can be added after a project definition has been initialised.

To do this, repeat the same procedure as described in “Section 3.5.1” to create a “Mechanical” discipline using the information in the table below:

Discipline Display Name

Code Description DB Rang Start

(49)

49

www.aveva.com

© Copyright 1974 to current year.

(50)

www.aveva.com

The form shows the new discipline in the discipline table but it is unmarked because databases for that

discipline have not been created.

New disciplines cannot be added at Global Satellites

Click the Update Project Data button to confirm the addition of the new discipline to the existing project data.

Click the Yes button to add the new discipline to existing project data.

The discipline list shows a green tick for the new discipline that has been defined.

A summary of actions taken by the system is output to the Summary panel and recorded in a log file.

(51)

51

www.aveva.com

© Copyright 1974 to current year.

The system adds new master database and maturity extract databases for the new discipline, along with consumer extracts to share other disciplines data with the new discipline and vice-versa. New teams are created with MDBs for the new discipline. Other disciplines MDBs are modified to add consumer extracts for the new discipline.

Create Project Baselines

To simplify Inter-disciplinary Project Baseline Setup an automation process has been implemented to allow users to, create BaselineTeam Databases and MDBs. When the automation process is run, consumer extract databases for each discipline are created and included in the MDB for that baseline. The MDB contains the baseline consumer extracts and loads databases from the common database set used in discipline MDBs.

To run the Inter-disciplinary Project Baseline Setup, select menu command Utilities>Inter-disciplinary Project Data>Baseline to configure project data baselines.

(52)

www.aveva.com

Click the New button to add a new

Baseline element and add a row to the end of the table for that element.

Baseline elements cannot be created or modified at a Global satellite

To delete Baseline elements one or more rows in the table must be selected for the Delete function to become available

In the Baseline form, enter the following data: Name: ACE

The element Name can be defined and modified at any time before or after a project definition has been created. Name can be entered with or without the preceding ‘/’. Spaces are removed from names before submitting changes to the database

ID (Required): ACE

The ID alphanumeric Text field can be used in automatically generated database and MDB names. Baseline ID must be unique and must not contain symbols or spaces

The after Baseline databases have been created the Baseline ID cannot be modified

Description: AVEVA Controlled Object Engineering

The Description of the Baseline. can be changed at any time

Click the Create Database button to create the Project Baseline Database. One or more rows in the table must be selected for the Create Databases function to become enabled.

The selected baselines must have a valid ID and must not have databases associated with them

(53)

53

www.aveva.com

© Copyright 1974 to current year.

The Project Baseline setup creates a team with a name convention <base name>BL. This team is used by all baselines, so it is only created when the first baseline is created.

(54)

www.aveva.com

The Project Baseline setup creates an MDB for the baseline, MDB names are <Base name>_<Baseline

ID>_BL. The MDB contains the baseline extracts and loads databases from the common database set used in the discipline MDBs.

Immediately after the baseline extract databases have been created the Summary panel contains messages generated by the system along with a Details button which links to a log file that records the objects created, along with any warning messages.

(55)

55

www.aveva.com

© Copyright 1974 to current year.

Create Users for Inter-disciplinary Project Data

The Inter-disciplinary Project setup automation process has not been configured to create Users. The Users are created separately by the Administrator after the creation of the Inter-disciplinary Project Data.

Create Users for Mechanical, Instrument and Electrical disciplines using the information in the table below:

Name Description Password

JNR.ELEC-A Junior Electrical Engineer A ENG JNR.ELEC-B Junior Electrical Engineer B ENG

SNR.ELEC-A Senior Electrical Engineer A ENG

SNR.ELEC-B Senior Electrical Engineer B ENG

JNR.INST-A Junior Instrument Engineer A ENG JNR INST-B Junior Instrument Engineer B ENG SNR.INST-A Senior Instrument Engineer A ENG SNR.INST-B Senior Instrument Engineer B ENG JNR.MECH-A Junior. Mechanical Engineer A ENG JNR.MECH-B Junior. Mechanical Engineer B ENG SNR.MECH-A Senior. Mechanical Engineer A ENG SNR.MECH-B Senior. Mechanical Engineer B ENG

SYSTEM.ENG System Engineer ENG

Make the Users members of the relevant teams as shown:

Team Team Members (Users)

ELECWORK JNR.ELEC-A JNR.ELEC-B ELECAPRV SNR.ELEC-A SNR.ELEC-B ELECRLSD ACEBL SYSTEM.ENG

(56)

www.aveva.com

 Electrical Team for Work Maturity / Extract Level

(57)

57

www.aveva.com

© Copyright 1974 to current year.

Team for Project Baseline

Using the procedure described above, make the following Users members of the relevant teams as shown:

Team Team Members (Users)

MECHWORK JNR.MECH-A JNR.MECH-B MECHAPRV SNR.MECH-A SNR.MECH-B INSTWORK JNR.INST-A JNR.INST-B INSTAPRV SNR.INST-A SNR.INST-B

(58)

www.aveva.com

Exercise 3 – Inter-disciplinary Project Data

1. Using existing “ACE” Inter-disciplinary Project Data definitions create the following Disciplines:

Discipline Display

Name Code Description DB Rang Start

PIPING Piping PIPE Piping 250605

PROCESS Process PROC Process 250601

(59)

59

www.aveva.com

© Copyright 1974 to current year.

3. Create a new Project Data Baseline using the information in the table below:

Name ID (Required) Description

ACE-2 ACE2 AVEVA Controlled Object Engineering

4. Create the Users for Piping, and Process discipline using the information in the table below:

Name Description Password

JNR.PIPER-A Junior Piping Engineer A ENG

JNR.PIPER-B Junior Piping Engineer B ENG

SNR.PIPER-A Senior Piping Engineer A ENG

SNR.PIPER-B Senior Piping Engineer B ENG

JNR.PROCESS-A Junior Process Engineer A ENG

JNR PROCESS-B Junior Process Engineer B ENG

SNR.PROCESS-A Senior Process Engineer A ENG

SNR.PROCESS-B Senior Process Engineer B ENG

5. Make the following Users members of the relevant teams as shown:

Team Team Members (Users)

PROCWORK JNR.PROCESS-A JNR.PROCESS-B PROCAPRV SNR.PROCESS -A SNR. PROCESS -B PIPEWORK JNR.PIPER-A JNR.PIPER-B PIPEAPRV SNR.PIPER -A SNR.PIPER -B ACE2BL SYSTEM.ENG

(60)
(61)

61

www.aveva.com

© Copyright 1974 to current year.

4

Engineering Element Types and Attributes Definition (LEXICON Module)

This chapter will extensively cover the creation and setup of the basic but fundamental elements required for defining a standard engineering data model.

These are contained within the following sections for: - User Defined Element Types (UDETs) - User Defined Attributes (UDAs)

- Definition of Distributed attributes and their owners - Database Views

These will be structured as engineering objects owning their generic attributes, and also owning distributed attributes which are collected within disciplines. Macros will be supplied to support the exercises.

The created element will then be appended to Database Views, which are setup with attribute and expression columns. The Database Views will serve as the basis for the creation of Engineering Lists etc.

(62)

www.aveva.com

Using the AVEVA Administration 1.3.0 product, log into the supplied project with the details as shown:

PROJECT: ACE

USER: SYSTEM

PASSWORD: XXXXXX

MDB: ADMIN-LEXICON

(63)

63

www.aveva.com

© Copyright 1974 to current year.

4.1

Engineering Objects (UDETs) definition- A Worked Example

Engineering objects are created as User Defined Element Types (UDETs), and assigned generic attributes.

As the LEXICON module reads and writes to the Dictionary database, the administrator should ensure that all required dictionary databases are available as appropriate. This also includes all team memberships and user access rights as covered in the preceding chapters

Creating a UDET world (UDETWL)

Select the topmost element in the dictionary explorer (Dictionary World), click the ‘Create’ entry on the menu bar, or right click to display the context menu and click the ‘Create’ > ‘UDETWL: User defined element world’ entry, to create a User

Defined Element World.

Within the Current Element Editor, fill in the attribute details of the created UDETWL world as shown.

Dictionary items can be created from the ‘Create’ button on the menu bar, or creation commands can also be entered as command line syntax in the command window

(64)

www.aveva.com

Creating a

group (UDETGR)

Select the newly created UDET world, display the context menu and click ‘Create’ > ‘UDETGR: User defined element group’ to create a User defined element group

Within the Current Element Editor, fill in the attribute details of the created UDET group as shown.

Creating a

UDET

Select the newly created UDET group, display the context menu and click ‘Create’ > ‘UDET: User defined element

to create a User defined element

Within the Current Element Editor, fill in the attribute details of the created UDET as shown.

This creates an engineering element type with user defined name: ‘EQUIPMENT’ with basetype ‘ENGITE’, from which objects / equipment tagged items can be based. The Equipment object can also own other equipment objects if :EQUIPMENT is selected as its ‘Member type’. Selecting ‘ENGGRP’ indicates that engineering objects can only be created within an ENGGRP db element within the Tags Application. Using the methods demonstrated, more user defined element types are created and named as shown:

- Instrument - Valve - HVAC - Line - InstLoop - Nozzle

(65)

65

www.aveva.com

© Copyright 1974 to current year.

Do note that all created items refer to the Basetype ‘ENGITE’.

The ‘NOZZLE’ element type refers to the ‘:EQUIPMENT’ and ‘ENGITE’ as its ‘Owner types’.

The ‘INSTRUMENT’ element type refers to the :INSTLOOP and ENGGRP as its ‘Owner type’, whilst the ‘:INSTLOOP’ refers to the ‘INSTRUMENT’ as its ‘Member type’.

References

Related documents