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

Engineering Administration

TM-3652

TRAINING GUIDE

AVEVA Engineering (14.1)

www.aveva.com

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

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

Reviewed

28/05/2014 30/05/2014

0.1 0.2

Issued for Review Reviewed

HU HU / KI

JB

09/06/2014 18/06/2015

1.0 2.0

Approved for Training 14.1 Approved for Training 14.1.SP1

HU / KI HU / KI

JB JB

Approved

GC 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 www.aveva.com such permission is © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

3


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 Fluent TM 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.


4

Contents 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 www.aveva.com Exercise 4 – Create Distributed Attribute Group UDETs and UDAs ........................................................ 80 © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

5

AVEVA Engineering (14.1) Engineering Administration (TM-3652) 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 www.aveva.com Mapping Continuation Area to Cases – A Worked Example ................................................. 167 © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6

AVEVA Engineering (14.1) Engineering Administration (TM-3652) Mapping Continuation Area to Sublist – A Worked Example ................................................. 169 Mapping Symbols to Datasheet Template ................................................................................. 171 Mapping Symbols to Datasheet Template - A Worked Example ............................................. 171 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 3.1 Pseudo Attributes Associated with Distributed Attributes ..................................................... 255 6.4 6.5 6.6


7



8

CHAPTER 1

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. www.aveva.com © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

9



10

CHAPTER 2

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’.


11


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:


12


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:

The procedures are contained within recommended steps during a project configuration as shown:


13


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.



2.1

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

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.


14


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.


15


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 This also incorporates the setup and application of Unit Sets and interdisciplinary data subscriptions. www.aveva.com © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

16


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.


17


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.


18

CHAPTER 3

3

3.1

Project Setup for AVEVA Engineering (Admin Module)

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:     

3.2

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.

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 by the trainer. They will typically be similar to this:


19




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.


20


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 www.aveva.com

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

21


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 APROCENG


22




Create three (3) different “Users” as shown.


23


USERS

PASSWORD

ELEC.ENGINEER A MECH. ENGINEER A PROC. ENGINEER A Make the Users members of the following teams: TEAM TEAM MEMBER

AELECENG ELEC.ENGINEER

TEAM…………………………………………AMECHENG TEAM MEMBER MECH.ENGINEER


24


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

For further details, on creation of Teams and Users, please refer to AVEVA Plant System Administration www.aveva.com User Guide (TM1300) © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

25




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 AMECHENG from the Owning Team grid Name column.

Enter or select the following data: Name

TAGSMATER.

Description

Mechanical Items (Tagnames-ENGWLD)

Database Type

Engineering


26


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

Click the Apply button to create the database.


27


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 AELECENG from the Owning Team grid Name column. Enter or select the following data: Name

ENGIELECTDIST

Description

Distributed Electrical Attribute Data

Database Type

Engineering


28


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


29


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 www.aveva.com


30


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.

Select the Explore tab from AVEVA Tags main toolbar to view the created database worlds as shown.


31


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.


32


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.


33


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.


34


Click the Create button to display the Create Discipline form.


35


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


36


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 INSTRUMENT

Display Name Instrument

Code

Description

DB Rang Start

INST

Instrument

250604


37


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.


38


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.

In the Maturity form, clicking the New button adds a row to the end of the table for that element.


39




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:



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):



Released

RLSD

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

www.aveva.com


40




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 APPROVE WORK

Display Name Approve Work

Code

Description

APRV WORK

MATURITY APPROVE 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 Interdisciplinary Project Setup creation using existing Administration DB Set functions as shown:


41




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 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 Utilities>Interdisciplinary Project Data>Manage.


42


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


43


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.


44


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.

www.aveva.com


45




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. www.aveva.com © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

46


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.


47


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 MECHANICAL

Display Name Mechanical

Code

Description

DB Rang Start

MECH

Mechanical

250603


48


Select Utilities>Inter-disciplinary Project Data>Manage to display the Inter-disciplinary Project Data form.


49


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.


50


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.

The Baseline form is then displayed.


51


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

The Project Baseline Name column in the table shows a green tick for the newly defined Baseline.


52


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

A Consumer extract database is created for each discipline and included in the MDB for that baseline.


53


The Project Baseline setup creates an MDB for the baseline, MDB names are __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.


54


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 JNR.ELEC-A JNR.ELEC-B SNR.ELEC-A SNR.ELEC-B JNR.INST-A JNR INST-B SNR.INST-A SNR.INST-B JNR.MECH-A JNR.MECH-B SNR.MECH-A SNR.MECH-B SYSTEM.ENG

Description Junior Electrical Engineer A Junior Electrical Engineer B Senior Electrical Engineer A Senior Electrical Engineer B Junior Instrument Engineer A Junior Instrument Engineer B Senior Instrument Engineer A Senior Instrument Engineer B Junior. Mechanical Engineer A Junior. Mechanical Engineer B Senior. Mechanical Engineer A Senior. Mechanical Engineer B System Engineer

Password ENG ENG ENG ENG ENG ENG ENG ENG ENG ENG ENG ENG ENG

Make the Users members of the relevant teams as shown: Team ELECWORK ELECAPRV ELECRLSD ACEBL © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

Team Members (Users) JNR.ELEC-A JNR.ELEC-B SNR.ELEC-A SNR.ELEC-B SYSTEM.ENG

www.aveva.com 55




Electrical Team for Work Maturity / Extract Level

Electrical Team for Approve Maturity / Extract Level


56


Team for Project Baseline

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

Team MECHWORK MECHAPRV INSTWORK INSTAPRV

Team Members (Users) JNR.MECH-A JNR.MECH-B SNR.MECH-A SNR.MECH-B JNR.INST-A JNR.INST-B SNR.INST-A SNR.INST-B


57


Exercise 3 – Inter-disciplinary Project Data 1. Using existing “ACE” Inter-disciplinary Project Data definitions create the following Disciplines: Discipline PIPING PROCESS

Display Name Piping Process

Code

Description

DB Rang Start

PIPE PROC

Piping Process

250605 250601

2. Update the “ACE” Inter-disciplinary Project Data.


58


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

Name ACE-2

ID (Required) ACE2

Description AVEVA Controlled Object Engineering

4. Create the Users for Piping, and Process discipline using the information in the table below: Name JNR.PIPER-A JNR.PIPER-B SNR.PIPER-A SNR.PIPER-B JNR.PROCESS-A JNR PROCESS-B SNR.PROCESS-A SNR.PROCESS-B

Description Junior Piping Engineer A Junior Piping Engineer B Senior Piping Engineer A Senior Piping Engineer B Junior Process Engineer A Junior Process Engineer B Senior Process Engineer A Senior Process Engineer B

Password ENG ENG ENG ENG ENG ENG ENG ENG

5. Make the following Users members of the relevant teams as shown: Team PROCWORK PROCAPRV PIPEWORK PIPEAPRV ACE2BL

Team Members (Users) JNR.PROCESS-A JNR.PROCESS-B SNR.PROCESS -A SNR. PROCESS -B JNR.PIPER-A JNR.PIPER-B SNR.PIPER -A SNR.PIPER -B SYSTEM.ENG


59



60

CHAPTER 4

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.


61


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

PROJECT: USER: PASSWORD: MDB:

ACE SYSTEM XXXXXX ADMIN-LEXICON

Click on the ‘LEXICON’ tile, to launch and display the LEXICON module.


62


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


63


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 - Line - Valve - InstLoop - HVAC - Nozzle


64


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’.


65


4.2

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

Existing User Defined attributes can be appended to any created Engineering element type, but new attributes can be created as required:

Creating a UDA world (UWRL)

Select the topmost element in the dictionary explorer (Dictionary World), click the click ‘Create’ > ‘UWRLD: User defined attribute world’ to create a User Defined attribute World.

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



The creation commands can also be entered as command line syntax in the command window

Creating a UDA group (UGRO)

Select the newly created UDA world, display the context menu and click ‘Create’ > ‘UGROUP: User defined attribute group’ to create a User defined attribute group.

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


66


Creating a UDA Select the newly created UDA group, display the context menu and click ‘Create’ > ‘UDA: User defined element’ to create a User defined element group.

Within the Current Element Editor, fill in the attribute details of the created UDA as shown. Name: Description: Abbreviation Length: UDA type: Abbreviation Length: Element type: User defined name: Reporter Text: UDA Category:

TagLetter Tag Letter 9 Text 5 :EQUIPMENT :INSTRUMENT : NOZZLE :VALVE TAGLETTER Tag Letter TagDefinition

Created UDAs are assigned to selected element types with the ‘Select element types’ form. Selected Element types are: Equipment Instrument Nozzle Valve



A UDA can be assigned to up to 100 engineering elements as required


67


Creating a referenced UDA A referenced UDA is one which references an existing element type. It could be used to obtain specific information from an object based on the referenced type. Just as accomplished earlier, select the newly created UDA group, display the context menu and click ‘Create’ > ‘UDA: User defined element’ to create a User defined element group Within the Current Element Editor, fill in the attribute details of the created UDA as shown. Name: Description: Abbreviation Length: UDA type: Abbreviation Length: Element type: Referred type: Indexed UDA: User defined name: Reporter Text: UDA Category:

NozzleConnection Nozzle Connection 8 reference 120 : NOZZLE :EQUIPMENT True NOZZCONN Tag Letter TagDefinition

With this Nozzle UDA in this example, an Equipment item can be referenced, as well as attributes of the referenced Equipment. This could be used for identification purposes or to obtain complex attribute values. Setting the ‘Index UDA’ to True enables a ‘Reverse Reference’, in which Nozzle Sub lists can be setup within an engineering Equipment list.


68


As noted earlier, existing UDAs can be referenced by an engineering element as appropriate. UDAs cache could also be imported via DBListings or Excel and assigned to existing elements. The supplied training project contains a cache of UDAs which could be utilised by the trainee. Efforts have been made to group these UDAs according to engineering disciplines, making them available to be assigned to the appropriate element types which might require them. Many of these UDAs can also be assigned as ‘Distributed attributes’ as demonstrated in the following section.

Graphical views of elements and attributes To gain an overall layout view of the attributes assigned to all available engineering objects click ‘Graphical View’ to display a schematic representation:


69


4.3

Distributed Attributes- A Worked Example

Distributed attributes could simply be defined as a cluster or collection of attributes of an element. Each collection could be based on any criteria, and could be managed independently by different appropriate users concurrently without laying claim to the main engineering object.

This training course assumes the collections of distributed attributes to be by discipline. Users of each defined discipline will be able to create, modify and manage the attribute values assigned to their discipline. For the created engineering object (:EQUIPMENT) element type, the nominated disciplines are: -

Electrical Mechanical Process

Each collection/discipline is represented by a ‘Distributed UDET’. A distributed UDET is created as a User defined element type which is based on a special basetype: ‘XPITEM’ (‘Distributed Attribute base element’). All attributes assigned to an XPITEM based UDET is referred to a ‘Distributed Attribute’.



Each distributed element is tied to a nominated Owner (Owning engineering object). The nomination of these elements will be described in subsequent sections



Although the Engineering object is stored in an engineering (ENGI) Database, its distributed attributes can be stored in separated engineering databases. The ability to read, create or modify an attribute is dependent on the read/write access to the database which holds www.aveva.com the attribute values


70


Creating a Distributed UDET Using the procedures described earlier, create a new UDET to group distributed elements, then a User Defined Element Type with basetype ‘XPITEM’ as shown:

Name: MECHANICAL-ATTRIBUTES Description: Mechanical Attributes User defined name: MECHANICAL-DATA Base type: XPITEM Owner Types: XPIFLD

This creates a distributed element UDET, with basetype ‘XPITEM’, whose attributes will be discipline specific. Using the methods demonstrated, 4 more user defined element types (XPITEMs) are created with user defined names as shown: -

INSTRUMENT-DATA VALVE-DATA INSTLOOP-DATA ELECTRICAL DATA


www.aveva.com 71


From groups of attributes (UDAs) created earlier, the appropriate discipline attributes are assigned to the created distributed elements (XPITEMs) as demonstrated earlier (Similar with the assignment of UDAs to UDETs).



For each distributed element, assign the appropriate discipline attributes as shown


72


Using the graphical view functionality, all existing distributed elements can be viewed, with the attributes assigned to them:

4.4

Distributed Attributes Definition

Having created all required User Defined Element Types (ENGITEs) / Engineering object types, User Defined Attributes (UDAs) (as required by the relevant disciplines), and the Distributed UDETs (XPITEMs) the distributed attribute definitions can now be setup. A distributed attribute definition could be setup according to the schematic diagram shown:

Default Home Definition

Distributed attribute Schema


73


For a multi discipline project setup, the distributed attribute definition helps performs the following functions: - Specifies a main engineering object which holds attributes for various disciplines(Binding Element) - Assigns discipline objects (Distributed udets) to a main engineering object - Specifies the location where discipline attributes will be stored. Each block on the diagram is defined as shown:

DSXWLD

Distributed Attribute Definition world: This is a container which holds all definition elements

DSXGRP

Distributed Attribute Definition group: This is an administrative level that helps with organising the definition elements

DSXHOM

Default Home Definition: This element defines locations where distributed UDETs are created

DSXDST

Default Home Destination Definition: This specifies a database location for the creation and storage of distributed attributes

DSXTST

Default Home Test Definition: This contains an expression which needs to evaluated before the default home can be used

DSXSCH

Distributed Attributes Schema: This element defines the relationship between a main element (ENGITE) and distributed elements (XPITEM)

DSXOWN

Binding Elements Definition: This defines the main engineering element (ENGITE) which will reference the distributed elements (XPITEM)

DSXMBR

Bound Elements Definition: This defines the distributed elements (XPITEM) to be referenced by the owning DSXOWN (ENGITE)


74


A configured sample definition could be structured as shown:

Creating a Distributed Attributed Definition World (DSXWRL) Select the topmost element in the dictionary explorer (Dictionary World), or the ‘Create’ button on the menu bar and follow ‘Create’ > ‘DSXWLD: Distributed Attribute Definition world’ to create a Distributed Attribute Definition world.

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

Creating a Distributed Attribute Definition Group (DSXGRP)

Select the newly created DSX world, display the context menu and click ‘Create’ > ‘DSXGRP: Group for Distributed definitions’ to create a distributed definitions group


75


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

Creating a Default Home Definition (DSXHOM)

Select the newly created DSX group, display the context menu and click ‘Create’ > ‘DSXHOM: Default Home Definition’ to create 2 default home definition

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



A DSXHOM for ‘PIPING ATTRIBUTES HOME’ is also created as demonstrated earlier


76


Creating a Default Home Destination Definition (DSXDST)

Select the newly created DSX Home, display the context menu and click ‘Create’ > ‘DSXDST: Default Home Destination Definition’ to create 2 default home destination definition for both DSXHOMs

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



‘XPIFLD’ is specified in the creation of the Distributed element, as an Owner / container of distributed items

The entry for ‘Home Location’ is a PML 1 expression which references the name of the XPIWLD hierarchy level (in the Engineering database explorer) where distributed elements (disciplines) and their attributes are to be created and stored.


77


Creating a Distributed Attributes Schema (DSXSCH)

Select the created DSX group, display the context menu and click ‘Create’ > ‘DSXSCH: Distributed Attributes Schema’ to create a distributed attributes schema.

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

Creating a Binding Elements Definition (DSXOWN)

Select the created DSX Schema, display the context menu and click ‘Create’ > ‘DSXOWN: Binding Elements Definition’ to create a binding elements definition.

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


78


Creating a Bound Elements Definition (DSXMBR)

Select the created DSX Schema, display the context menu and click ‘Create’ > ‘DSXMBR: Bound Elements Definition’ to create 2 bound elements definition.

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

Name: Default home: Auto Creation: Cardinality: Element types:

LINE-PROCESS-DATA LINE-PROCESS-ATTRIBUTES-HOME True 0, 1 :PROCESS-DATA

The ‘Default home’ entry displays a pick list which contains any existing Default home definitions (DSXHOM). Selecting a default home means that a referenced distributed element type (DSXMBR) can be created and stored at the database location (DSXDST) specified by the default home (DSXHOM) ‘Cardinality’ helps specify the minimum and maximum number of each of the assigned attributes which may be created. For Example, a cardinality of (0, 2) means that the distributed element :PROCESS-DATA will have 2 instances of the attribute :MAXFLOWRATE (:maxflowrate1, :maxflowrate2) Setting the ‘Auto Creation’ entry to ‘True’ ensures that the distributed element will be automatically created when a distributed attribute value is filled in at the first instance.

www.aveva.com


79




A DSXMBR for ‘PIPING DATA’ is also created as demonstrated earlier



The nominated Element Types specifies the XPITEM based UDET, which will be considered as a distributed element, and whose attributes will be referenced by an ENGITE (DSXOWN)

Viewing the Distributed attributes definition

Select the created Binding elements definition (DSXOWN), display the context menu and click ‘Graphical View’ to display the graphical view representation of the Distributed attributes definition.

Exercise 4 – Create Distributed Attribute Group UDETs and UDAs Using the supplied ACE project: - Configure the distributed definition for Equipment, Valve and Instrument element types - Display the graphical views of all definitions


80


4.5

Status Definitions-

A Status definition is the implementation and structuring of the Status Control mechanism.

Status Control is the ability to control and report on the defined status of model objects as they progress through their lifecycles. It can be applied to any model objects, like tagged schematic/ 3D and engineering items, catalogue components, drawings etc. A status definition is an administrative task carried out within the LEXICON module, and could be project dependent. A definition incorporates the use of a hierarchy of Status World, Status Definition and Status Value elements. This section describes how to create, assign and utilise status definitions in an engineering project.

Creating Status Reasons Status reasons is a configurable function with which allows for the definition of mandatory reasons to be selected during status transitions. This means that when a status change is being made, the user can select a reason from a pick list of configured reasons. The status reason is defined with a new dictionary element (UDLOV) which is used to manage a new text attribute ‘Reason’. The reason will be assigned to a Status value (STAVAL), and can be visible as a pick list within the Status edit form in the Tags module. Create a new UDA group (UGRO) and 2 UDLOVs as shown:


81


Enter the attributes for the UDLOV (ApproveReasons) as shown:

Name: Valid Values:

Value Type:

ApproveReasons ‘For Calculation check’ ‘For safety check’ ‘For general check’ Text

Create and enter the attributes for the second UDLOV (ReleaseReasons) as shown:

Name: Valid Values:

Value Type:



ReleaseReasons ‘For Construction’ ‘For tender’ ‘For review’ ‘For Design’ Text

The status reasons created will be utilised during the definition of both the ‘Approved’ and ‘Released’ status values (STAVAL) www.aveva.com


82


Create Status Configuration world (STAWLD) 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’ > ‘STAWLD: Status Configuration World’ entry, to create a Status Configuration world.

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

Create Status Definition (STADEF)

Select the created Status configuration world STAWLD, display the context menu and click ‘Create’ > ‘STADEF: Status Definition’ to create Status Definition.

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


83


Name: Description: Initial Status:

ENGR-STATUS-DEFINITION Status definition for Engineering items Identified

Controllable element types; These are the element types on which the Status control mechanism will apply to within this Status definition. Controllable element types will include both Engineering items (ENGITE) and Distributed elements (XPITEM)

Create Status Value (STAVAL)

Select the created Status definition STADEF, display the context menu and click ‘Create’ > ‘STAVAL: Status Value’ to create Status Value.

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

Name: Description:

IDENTIFIED Identified

Each Status value represents a possible status transition level © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

www.aveva.com 84


Select the created Status definition STADEF, display the context menu and click ‘Graphical View’ to display the graphical view representation of the status values.

Select the created Status definition STADEF, display the context menu and click ‘Create’ > ‘STAVAL: Status Value’ to create further Status Values. Within the Current Element Editor, fill in the attribute details of the created STAVAL as shown.

Name: WORKING Description: Working Valid Trainsitions: IDENTIFIED Demote: IDENTIFIED

This status level is defined so that status level ‘IDENTIFIED’ transitions to the ‘WORKING’ status value after a promotion.


85


Select the created Status definition STADEF, display the context menu and click ‘Create’ > ‘STAVAL: Status Value’ to create further Status Values. Within the Current Element Editor, fill in the attribute details of the created STAVAL as shown.

Name: PENDING-APPROVAL Description: Pending Approval Reason Values: ApproveReasons Valid Trainsitions: WORKING Demote: WORKING This status level is defined so that status level ‘WORKING’ transitions to the ‘PENDING-APPROVAL’ status value after a promotion.

The ‘Reason values’ is defined for this status value (STAVAL), as it is required for this status. This means that when the user promotes the status of the engineering object from the ‘WORKING’ state to the ‘PENDING APPROVAL’ the dialogue form will carry a pick list with the specified reason values. The selection of a reason value in this case is mandatory.


86


Following the predefined Status Definition in the supplied training project, a completely configured project status definition could be structured to look as shown:



Status values (STAVAL) Promotion transitions are marked with the ‘GREEN’ arrows, while the Demotion transitions are marked with ‘RED’ arrows. ‘BLACK’ arrows mark natural transitions www.aveva.com


87


Exercise 5 – Status Control Using the supplied ACE project: - Reproduce the status control definition as shown in the example - Include status numbers to show the percentage achievement of each status level


88


4.6

Database Views Definition

A Database View is a Dabacon based functionality with which attribute data of elements can be collectively configured to map into the cells of a table. These tables can be generated as lists, indexes and reports. A Database View definition is based on any available element type, with column references to a selection of its attributes or expressions defined beneath. The Database View definition will allow a table to create and list instances of the element type (database items) in rows with the columns controlled by their selected attributes or expressions (PML 1 or XPath 1.0 expressions). In other words, as a Database View it supports a list view table, where each row of that table will be an instance of an element type(s), and the cells of each column will either be a value of an attribute or expression based on the corresponding row element.



It is possible for each row to represent data from multiple element types and also multiple database elements may be modified if a row of data is edited in a grid or via an import

Database Views control A generated engineering list consists of rows and columns, and is based on a Database View. Row entities are controlled by the applicable element types, as each row is an instance of that element type, hence a database item. Columns are controlled by element attributes or expressions, hence referred to as ‘Attribute Columns (ATTCOLS)’ and ‘Expression Columns (EXPCOLs)’

Attribute Columns (ATTCOLs)

Expression Column (EXPCOL)

Defined Database Views will consist of a base element type, and configurations for Attribute columns. Other configurations might include Expression columns, attribute filters and item Creation rules.


89


The Database View can also be defined for additional element types, making it possible to include their attribute and expression data onto the same list / table. These additional element types can be configured as ‘Source Elements’

For an engineering project setup, the Database Views definition helps performs the following functions: - Specifies the major element (UDET) which a list is based on - Specifies properties which are available as list attribute columns and expression columns - Defines the required contents and behaviour of an engineering list - Defines the creation requirements and criteria for list items - Defines the presentation structure of list items

Each block on the diagram is defined as shown:

DBVWW

Database View World: The top-level administrative element.

Database View Group: DBVWGR

Used to group definitions into manageable administrative sets, this is for administration only and is not visible to users in other contexts.

Database View Set: DBVWSE

Used to group Database Views for user presentation. These should contain related views as they are visible to the user. A Database View can be a member of a Database View Set even if it is not a direct member.


90


Database View DBVW

A table definition that defines the display name, element criteria and columns

Attribute Filter: ATTFIL

An attribute filter is a test executed against the selected element based on the value of a specified attribute such as DESC Equals Vessel. A database element must match all filters present in the Database View to be present in the resulting table

Expression Filter: EXPFIL

An expression that must evaluate to TRUE or FALSE to determine whether a database element is part of the database view. A database element must match all filters present in the Database View to be present in the resulting table

Attribute Column: ATTCOL

This is an element which defines columns based on a single attribute. Attributes may be system attributes or UDAs. Qualifiers can be specified where required such as when accessing the status of a particular element. Columns based on attributes are by default editable but can be made to be read only to help with workflow management

Expression Column: EXPCOL

This is an element which defines columns based on a PML or XPATH expression. Expression columns are read only unless software is written to make them editable.

Source Element: SRCELE

This is an element which defines a navigational step from the current context element to another database element. All columns defined in the Source Element are then based on the element that results from the navigation. Such columns are editable so rows in Database Views allow editing of more than one database element.


91


Creation Rule: CRERUL

This defines the rules for element creation. If within a DBVW element then the rules permit row creation for the Database View provided that the AUTCRE attribute is set to TRUE. Information such as where to create the new item or what type of element to create can be fixed or specified using expressions

Set Parameter: SETPAR

This is an element used to define parameters for expressions in other create rules. A parameter can be used in expressions on the CRERUL, SETATT or TESTEX elements. Parameters provide the ability to prompt a user for a single piece of information and then use it in multiple expressions

Set Attribute: SETATT

This defines a rule to set a database attribute when the element is created. This allows attributes to be defaulted at the point of creation and forces a user/application to provide a mandatory attribute value at the time of element creation.

Set Status Rule: SETSTA

This defines a rule to assign a status to the created item at the time of creation. This will help ensure all elements are being status managed

Test Expression: TESTEX

if this evaluates to true then the owning rule will be carried out, otherwise the owning rule is ignored

Column Relation: COLREL

This element defines a Parent/Child relationship between columns for application use. These relationships are currently not supported in the standard applications

Typical Database Views setup will have most of the hierarchical elements configured, but this depends on the purpose and use of resulting lists and tables based on the Database Views. The following sections will describe the definition steps of a Database View, and the configuration of its hierarchical elements.


92


Database Views Setup Database Views are defined via the Database Views Editor within the LEXICON and Tags modules, or with the Current Element Editor within the LEXICON module as was originally default. The Database Views Editor is a General user interface for the creation and definition of Database Views in a quick and user friendly manner.

The Current Element Editor includes the criteria for selecting and entering elements from which the rows are constructed, as well as all applicable attribute and expression data required for column control. As Database Views entries are placed in a hierarchical order beneath a Database View world in the dictionary explorer, the Current Element Editor defines the criteria for each entry in all levels of the hierarchy.

The following example will demonstrate the definition of a Database View for a mechanical equipment. Like previous examples, this utilises the supplied demo project.

Create Database Views World (DBVWWLD) Select the topmost element in the dictionary explorer (Dictionary World), right click to display the context menu. Select the ‘Create’ entry, to display a sub list of dictionary elements worlds, and select the ‘DBVWWLD: Database View world’ entry, to create a Database View world.

With the Current Element Editor, fill in the attribute details of the created DBVW world as shown.


93


Create Database Views Group (DBVWGR)

Select the created Database View world ‘ENGINEERINGDATABASE-VIEWS’, and Create a ‘Database View group’ (DBVWGR) using the context menu.

With the Current Element Editor, fill in the attribute details of the created DBVW world as shown.

Database Views (DBVW)

Select the created Database View group ‘MECHANICAL-VIEWS’, and Create a ‘Database View (DBVW) using the context menu.

The Current Element Editor form of the Database View includes entries for a ‘User Defined Name’, as this will be the identifier for the Database View. Required Element Type(s) can be selected, as list data will be based on this. ’Auto Creation’ is set to ‘True’ as this will allow the creation of new rows (new instances of the selected element type) on any generated list/table which is based on this Database View.


94




Setting the ‘Allow Deletion’ to ‘False’would make it impossible to delete an item from a list which is based on this Database view



The utilized element type :EQUIPMENT is an engineering UDET which has been pre-defined for this exercise

Attribute Columns (ATTCOL)

Select the created Database View ‘MECHEQUIPMENT-BASIC’, and Create an ‘Attribute Column’ (ATTCOL) using the context menu.

The section ‘Basic definition’, of the Current Element Editor form of the Attribute Column includes entries for a ‘User Defined Name’, as any entered value will be displayed as the default caption (Column header) of the column on a list/table. Required and applicable attributes which have been appended to the utilized element type can be filled in, as the column will be based on this attribute. The ’Read only’ entry is set to ‘False’ as this will allow the values within the list/table columns to be editable. Fill in the attribute details as shown.



The utilized Attribute :TAGNUMBER entry is an engineering UDA which has been pre-defined for this exercise. Utilized attributes must already have been predefined and exist

Create 4 more Attribute Column (ATTCOLs) as shown.


95


Expression Column (EXPCOL)

Select the created Database View ‘MECH-EQUIPMENT-BASIC’, and Create an ‘Expression Column’ (EXPCOL) using the context menu.

The section ‘Basic definition’, of the Current Element Editor form of the Expression Column includes entries for a ‘User Defined Name’, as any entered value will be displayed as the default caption (Column header) of the column on a list/table. Required and applicable expressions and the expression type are filled in, as the column will be based on this expression. Generated expression columns will be marked as ’Read only’ by default, as their cell values are derived, and not directly entered nor modifiable. Fill in the attribute details as shown.



Create an additional expression column (EXPCOL) for ‘Status’ definitions

Attribute Filter (ATTFIL)

Select the created Database View ‘MECH-EQUIPMENT-BASIC’, and Create an ‘Attribute Filter’ (ATTFIL) using the context menu.


96


The section ‘Basic definition’, of the Current Element Editor form of the Attribute filter includes entries for an attribute with which the filter will be based on. The ‘Filter operator’ defines the condition/criteria for the selected attribute. The ‘Filter value’ is a value which applies to the condition/criteria defined. In this case, any generated list/table based on this Database View will only display a :TAGNUMBER column which contains values starting with the characters ‘16’. Every other Tag number will be filtered out. Fill in the attribute details as shown.

Expression Filter (EXPFIL)

Select the created Database View ‘MECH-EQUIPMENT-BASIC’, and Create an ‘Expression Filter’ (EXPFIL) using the context menu.

The section ‘Basic definition’, of the Current Element Editor form of the Expression filter includes entries for an Expression, and Expression type with which the filter will be based on. The expression filter is utilized if the attribute filter is not sufficient to filter elements, but rather complex conditions are required. A PML type expression could be (:equiclass eq ‘Pump’). Expressions can be used to define conditions/criteria to filter values displayed in a generated list/table. This will not be filled in, as it is not required for this exercise. ‘Expression’ will be left ‘unset’.


97


Create Rule (CRERULE)

Select the created Database View ‘MECH-EQUIPMENT-BASIC’, and create a ‘Create rules’ element using the context menu.

The section ‘Basic definition’, of the Current Element Editor form of the ‘Creation rule’ includes entries for an ‘Owner Expression’, which is an identifier for the engineering group (ENGGRP) where new :EQUIPMENT type items / instances will be created and stored. The ENGGRP exists in the engineering database, and can be accessed via the Tags module. Its name will serve as the ‘Owner’ of any new EQUIPMENT items. The Owner Expression type indicates the type of expression used. The ‘Type expression’ entry requires an expression which identifies a specific element type which a created item is based on. This is not essential since the utilized UDET (:EQUIPMENT) can be derived. Defining the Creation rule ensures that each time a new item is being created on the Database View list / table, a prompt form appears requesting values for required or optional preconfigured parameters. Selecting ‘True’ for the ‘Create ancestors’ entry makes it possible for new items to be created and stored in any other existing ‘Owner element’ (ENGGRP) database hierarchy within the Tags module), if an ‘Owner Expression’ is not defined. The user will be prompted to select from an existing ENGGRP, or create a new one, during the creation of a new database item. Fill in the attribute details as shown.



This means that items created in a list based on this DB view, will be saved in the ENGGRP Mechanical-Items


98


Set Parameter (SETPAR)

Select the created Creation rule ‘MECHANICAL-VIEW-CRERULE’, and create a ‘Set Parameter’ element using the context menu.

The section ‘Basic definition’, of the Current Element Editor form of the ‘Set Parameter’ includes entries for a ‘User Defined Name’, as this value will be the identifier for the parameter. The value in the ‘Expression’ entry indicates that whenever this parameter is utilized, any expression value will be evaluated. The ‘Creation rule’ ensures that a prompt form for the entry of parameter is displayed during the creation of database items in the Tags module, hence the ‘User Prompt’ entry ‘Tag Number’ will be displayed on that form where the user can enter a relevant value. Setting the entry for ‘Required’ to ‘True’ ensures that this will be a mandatory requirement for item creation. If set to ‘False’ then the parameter entry on the prompt form will be listed as ‘Optional’. Fill in the attribute details as shown.

Create 4 further ‘Set Parameter’ rules and fill in the attribute details as shown.


99




The Tag Number, Tag Prefix and Tag Letter parameters will be displayed as a required (Required: True) entry on the ‘Creation rule’ prompt form, and entered values will be utilized in any expression in which they apply



The Tag Suffix parameter will be displayed as an optional (Required: False) entry on the ‘Creation rule’ prompt form, and entry of values is not mandatory


100


Set Attribute (SETATT)

Select the created Creation rule ‘MECHANICAL-VIEWCRERULE’, and create a ‘Set Attribute’ element using the context menu.

The section ‘Basic definition’, of the Current Element Editor form of the ‘Set Parameter’ includes entries for ‘Attribute’, as this is the selected attribute values will be controlled by the rule. The ‘Expression’ entries will extract the values to be utilised for the selected attributes of items to be created. In this case, the expression points to the defined parameters, as these parameter values are entered in the Creation rule prompt form. The entered parameter values will then be evaluated according to the expression, and a final value will be appended to the attribute of the newly created item. The ‘Required’ entry is set to ‘True’, ensuring that the application of this rule is mandatory. Create 2 further ‘Set attribute’ rules and fill in the attribute details as shown.



Enter the expressions '/$!TGPre-$!TGLet-$!TGNum-$!TGSuf' for ‘Mechanical Tag name rule’, ’ $!TGPre for the Tag Prefix rule, $!TGLet for the Tag Letter rule, $!TGNum for the Tag Number rule and '$!TGSuf' for the ‘Tag Suffix’ rule


101


Set Status (SETSTA)

Select the created Creation rule ‘MECHANICAL-VIEWCRERULE’, and create a ‘Set Status’ element using the context menu.


102


The section ‘Basic definition’, of the Current Element Editor form of the ‘Set status’ includes entries for ‘Status Definition Ref’, as this allows the user to select from a drop down list, a required status definition with which this rule applies. The Set status rule appends the Initial status value of the selected status definition to newly created items on a Database View list / table. The ‘Required’ entry is set to ‘True’, ensuring that the application of this rule is mandatory. Fill in the attribute details as shown.



The utilized Status definition ref ‘ENGRSTATUS-DEFINITION’ was previously created and already exists for the purpose of this exercise



When a new engineering item is created, it will be appended with the initial status value defined for the selected status definition


103


Source Element (SRCELE)

Select the created Database View ‘MECH-EQUIPMENT-BASIC’, and Create a ‘Source element’ (SRCELE) using the context menu.

The section ‘Basic definition’, of the Current Element Editor form of the source elements includes an entry for ‘Expression’, in which an expression extracts the element type whose attribute data will be defined beneath. In this case,selected attribute data of the distributed UDET (:PROCESS-DATA) will be populated and available on the same Database View list / table together with the attributes of the ‘:EQUIPMENT’ UDET. Although the ‘Expression’ entry can reference the distributed UDET (:PROCESS-DATA), other expressions can be formulated to extract attribute values from other element types or UDET as a source element. Fill in the attribute details as shown.



The Database View list / table will now be able to contain and display attribute data from the source element, as well as the original selection of attribute data from the original engineering UDET

Select the created Source element ‘MECHANICALEQUIPMENT-PROCESSDATA’, and Create attribute columns (ATTCOLS) as shown.


104




The UDETs which are referenced as source elements were earlier defined for this exercise



Expression columns (EXPCOL) and Creation rules (CRERULES) can also be created as described previously



The attributes (e.g. :NORMOPPRESS, :NORMOPTEMP) utilized for the attribute columns, must be defined for the UDETs of the source elements

Select the created Database View ‘MECH-EQUIPMENT-BASIC’, and Create another ‘Source element’ (SRCELE) using the context menu. Then select the created Source element named ‘MECHANICAL-EQUIPMENT-ELECTRICAL-DATA’, and Create attribute columns (ATTCOLS) for (:MOTORSPEED and :RATEDTORQUE) as shown.


105


Preview created Database View list/table Within the AVEVA Engineering – Tags module, create and display a new list / table from a suitable category, and based on the previously created Database View.

DB View Element (UDET)



Source Elements (SRCELE)

See AVEVA Engineering 14.1 Basic guide for the creation and display of a list within the Engineering application

Database View Set (DBVWSE)

Select the created Database View group ‘MECHANICAL-VIEWS’, and Create a ‘Database View Set (DBVWSE) using the context menu.

The section ‘Basic definition’, of the Current Element Editor form of the Database View includes just an entry for a ‘User Defined Name’, as this is what the Database View Set will be identified with.


106


The Database View Set is simply a collection of created Database Views as required. Database View Sets can be created to hold a number of Database Views which apply to a specific element type, a discipline, or tasks.

Click on any existing Database View, drag and drop into the created Database View Set.



The Database View Sets shown was defined using additional Database Views configured for this demonstration

Database View management Database Views and Database View Sets can be managed within Definition sets, although these Definition sets are not exposed to the user via the Current Element Editor. A Definition set are areas where the Database Views are created and placed, as well as modified and updated. These Definition sets include:   

Element View – Database Views defined automatically to represent the database hierarchy, and includes all available element types within the MDB utilized. Project Views – Database Views defined in the dictionary database for a project. User Views – Database Views defined as a file in the users project setting

These Definition sets are visible and manageable from within the Database Views Editor.



Refer to Chapter 8 for more information on the configuration and use of Database Views and Database Views Sets within the Database Views Editor


107


Exercise 6 1. Using engineering UDETs and existing Database Views available in the supplied ACE project define a Database View with the Current Element Editor as described in the examples 2. Create Attribute columns and expression columns beneath the Database View as earlier described 3. Create an Attribute filter 4. Create ‘Creation rules’ 5. Create ‘Set Parameters’ and ‘Set attribute’ rules 6. With the engineering UDETs utilized, define another Database View with the Current Element Editor as described in the examples 7. Create Attribute and expression columns, a ‘Creation rule’, and 2 source elements (using either a predefined distributed discipline (XPITEM), or any element type (As described in the examples)) 8. Create ‘Set Parameters’ and ‘Set attribute’ rules 9. Create a Database View Set, and place the created Database Views within, as described in the examples 10. Create and display a list / table within the Tags module, and view lists based on the created Database Views 11. Using the Database Views Editor, copy the created Database Views from their current Definition set and paste in the ‘User Views’ Definition set, or any user defined Definition set


108

CHAPTER 5

5

Interdisciplinary Project Data

It is possible to configure an AVEVA Engineering project for the revisioning of engineering objects. These objects could be engineering items (ENGITEs), Distributed attributes objects (XPITEMs), and datasheet instances (DSINST). The revisioning of items could be implemented within the ‘Controlled Object Revisioning’ concept. This concept supports the ‘Interdisciplinary Project Data’ procedures which allows for data control by the user, where by data changes can be made, approved and distributed to subscribers. Data changes of other users can also be received and consumed by the user.

The simplified diagram above describes a possible the Interdisciplinary project data workflow. In the case above, a user within the Process discipline modifies process data and submits for approval. The approve piece of work is then transitioned to the ‘Released’ maturity level where the data is now available for all subscribers to obtain and consume.



Refer to Chapter 3 for the creation and setup of a project for Interdisciplinary Projectwww.aveva.com Data


109


5.1

Controlled Object Revisioning

This chapter covers the configuration and setup of dictionary (LEXICON) elements required for the implementation of object revisioning and interdisciplinary project activities.



Revision configuration for datasheets instances will be covered in chapter 6 (Datasheet configurations)

Create Revision Configuration World (REVCWL) Select the topmost element in the dictionary explorer (Dictionary World), right click to display the context menu. Select the ‘Create’ entry, to display a sub list of dictionary elements worlds, and select the ‘REVCWL: Revision Configuration World.

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

Create Revision Configuration Group (REVCGP)

Select the newly created REVCWL, display the context menu and click ‘Create’ > ‘REVCGP: Revision Configuration Group’ to create a Revisions Configurations group


110


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

Create Revision Number Definition (REVNOD)

Select the newly created REVCGP, display the context menu and click ‘Create’ > ‘REVNOD: Revision Number Definition’ to create a Revision Number Definition.

The REVNOD element allows for the specification of revision numbering for controlled engineering objects. Here for example, a ‘working’ and an ‘issued’ numbering and number format can be defined for controlled objects after a status change.

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

Configure the revision number format by editing the REVNOD as described.


111


Select the newly created REVNOD, display the context menu and click ‘Edit Revision Number Definition’ and within the Revision Number Definition, fill in the entries details as shown.

‘Working revision text’ value will be appended to an object which is at a status referenced by this number definition. Enter an asterix (*) in the field. This will be further explained in the next section. ‘Number of Parts’ specifies the number of combined characters the numbering format should take on. For example, (A1, A2, B1, B2 etc.). Each part can be configured as a numeric or alphabetic characters.

With the ‘Formatting’ section of the form, the length of the revision number characters can be increased from 1 character to 10 characters (per part), with Alphabetic characters being padded with an ‘A’ or Numeric characters padded with a ‘0’.

For Example (AA1, AA2, AAA1, A01, A02, A03, A001 etc.).The ‘Fixed length’ check box will have to be checked before the length of the part can be increased.



Customised revision numbering texts/format can be utilised, from clicking on the ‘Custom’ radio button


www.aveva.com 112


Click the ‘Test’ button to preview the configured numbering format.

Click the ‘OK’ button to accept the changes.

The ‘Working revision text’ value (*) will now be visible in the entry field.

Create Revision Configuration (REVCON) Select the created REVCGP, display the context menu and click ‘Create’ > ‘REVCON: Revision Configuration’ to create a Revision Configuration.

For element name, enter: ENGRREVISION-CONFIGURATION’.


113


The revision configuration (REVCON) brings together essential elements required for the revisioning of objects. It allows for the selection and referencing of appropriate status definition (STADEF), revisioning numbering and relevant element types. Select the created Revision configuration ‘ENGR-REVISION-CONFIGURATION’, display the context menu and click Edit Revision configuration’ fill in the entries details as shown.

Click on the browse button to display the ‘Select Element Types’ form, and select the required objects which have their revisioning controlled by this configuration:

Include the following: :EQUIPMENT :INSTLOOP :INSTRUMENT :LINE :NOZZLE :VALVE :ELECTRICAL-DATA :MECHANICAL DATA :INSTLOOP-DATA :PIPING-DATA :PROCESS-DATA :INSTRUMENT-DATA :VALVE-DATA


114


Select the status definition from the pick list as shown. This selection will populate the pick lists of ‘Create working revision at:’ and ‘Issue revision at:’ entries with all available status values of the STADEF.

This means that when the status of an item (based on a selected element type) is changed to ‘working’, the revision number value (*) will be applied to that item. This is also the case when the status of an item is transitioned to ‘Issued’ state, then the revision number of that item will be applied to the object. (For example A1)



The Revision numbers on controlled objects are called from the value of a special attribute: ‘RVCURR’

Select the required revision number definition as shown:

The revision number mechanism will now apply to objects controlled by this revision configuration.



The Revision block definitions are required for the creation and setup of datasheets revision blocks. This will be demonstrated later in this guide

Click the ‘OK’ button to accept the changes.


115


Version Control configuration (VERCON)

Select the created REVCGP, display the context menu and click ‘Create’ > ‘VERCON: Version Control Configuration’ to create a Version control configuration.

Select the created Version control configuration fill in the entries details as shown.

The version Control configuration (VERCON) specifies the behaviour of an engineering object when it attains a defined status level. According to the pre setup maturity levels, extract objects will have data changes/modifications dynamically ‘Issued’ to the next higher level and revisioned as soon as that object has its status is set to a pre-configured value. This behaviour is demonstrable from within the Engineering Tags application.



Please see the AVEVA Engineering User training manual for details on controlling objects

Note: The VERCON element must be named. It has been named ‘Tags’ in this case. The required Revision configuration is selected from the pick list as shown: Selecting the Revision configuration will automatically have the ‘States to issue extracts’ pick list populated. This is because the Status Definition information (which includes Status values) is extracted from the selected revision configuration.


116


The ‘States to issue extracts’ allows for the selection of required status values from a pick form.

Click the ‘OK’ button to accept the changes. Data from the nominated element types are now ready to be transitioned across from an extract level to another (As configured).

Log into the Engineering Tags application as a user with access to the extract databases (For example a user at the ‘Working’ maturity level JNR.ELEC-A, MDB: ACE_ELEC_WORK) Set the status of a selected object to ‘Working’ this should dynamically give it the revision value of (*).

Make data changes and promote the status of that item to ‘Pending approval’. This should trigger a dynamic ‘Issue’. A user at the ‘Approving’ maturity level logged in as SNR.ELEC-A, MDB: ACE_ELEC_APRV will simply need to run a ‘Get work’. This will have his view updated with the data and changes made by the user within the lower extracts/level


117


If the approving user (Senior Engineer) at the ‘Approving’ maturity level is happy with the data, a promotion to an approved state can be initiated. This will trigger a dynamic ‘Issue’ where by the data will be made available to the master or ‘Released’ level and database. A revision number can also be selected during the promotion.



The Shared services mechanism will need to be setup and configured before the full functionality of interdisciplinary workflow can be tested. This is covered in the following Section

Exercise 7 1. Create a new revision configuration and revision numbering definition as demonstrated


118


5.2

Shared Services System

The AVEVA Shared Service Notification is the communications mechanism which firmly supports the Interdisciplinary project data work flow, as it allows for the exchange of object data between the users of the AVEVA Engineering Tags application. Each user will have to subscribe to a notification topic which could be object data from within disciplines of an AVEVA Engineering project. Data changes/modifications made within the subscribed data view generates a notification which is stored in a specified Dabacon database. Subscribing applications can then request (Getwork) a list of notifications against a subscription from the notification service. Basically, a notification is raised for an object data change after a status promotion has been initiated. This could be when the object is promoted to an ‘Approved’ status level. The VERCON mechanism will then trigger a dynamic ‘Issue’, in which the modified object will be issued from an extract level to the master databases (Released data). Users within other disciplines who are subscribed to the source of the change will then be notified (after a ‘Get Work’), and they can chose whether to accept the changes on that object or not (From the Revision Center form).

The notification service works on a ‘Server’ ‘Client’ basis, where the Engineering Tag users can have their machines setup as clients, and a Notification Server will be nominated. Each user will then have to point their client dll’s to this Server system.

This section covers the configuration and setup for the shared services mechanism according to the diagram shown:


119


Setting up a Notification Service Server The AVEVA Shared Services product must be installed on a nominated ‘Server’ machine, which is made accessible to required (allowed) client systems. It could be installed in the system/machine of a client/user. Although one Notification Service server location must be referenced by all users. The Shared Services installation comes as a Separate Product Lifecycle (SPL) install, so should have it’s ‘custom evars’ batch file containing a default pointers to sample and catalogue projects (amongst others) pointing to the correct project. This must be the same project that is accessed by the users. This batch file may be found in the location shown: Navigate to the ‘Custom Evars’ batch file in the ‘Projects 3.2’ (for example) folder of the AVEVA Shared Services installation as shown:



www.aveva.com

The location of the ‘Custom evars’ as shown below, assumes a standard product install


120


Open and display the contents of the ‘Custom Evars’ batch file in a suitable text application to view the contents of the file.

Click File > Save to save the changes made to the file.

Ensure that the Shared Service Notification Service is started: Open and display the Windows ‘Services’ application console by navigating to: Control Panel\All Control Panel Items\Administrative Tools

Select the ‘AVEVA Shared Service Notification Service’ entry, and click the ‘Start’ control, to get the services started. This essentially starts the Notification Shared Services server started and ready to receive and transmit data between subscribers and sources.



This services should be started by default normally after the Shared Services 3.1 product has been installed


121


Notification Service Client The Notification Service Client is basically the machine/systems of the users who will be working with the AVEVA Engineering application, creating/modifying or manipulating data. AVEVA Shared Services product does not have to be installed on the client users’ machines. The installation locations of both the AVEVA Engineering 14.1 and Administration contain an ‘AVEVA.SharedServices.Client.dll.config’ file. The contents of these files will have to be manually edited to point to the ‘Shared Services notification server’. The files can be found in the installation location of the Engineering 14.1 and Administration products within the clients’ machine:



The installation location of the products could be different from that displayed above

Navigate to and select the config file contained within the AVEVA Engineering installation as shown, open and display the contents on this file in a suitable text application. Then modify the contents by including the machine/system name of the server in which the Notification service has been installed as shown below:



The server names being used in the nodes are purely for example. The administrator must include the actual server names of their notification service server

www.aveva.com


122


Repeat the same actions described for the copy of the ‘AVEVA.SharedServices.Client.dll.config’ file contained within the AVEVA Administration product installation location. This will make it possible for the shared services notification manager to be able to receive information from the LEXICON module of the AVEVA Administration installation. The Shared Service Notifications service does not have to be started within the client machine.

These actions carried out will allow the communication links between the Notification Service server, and the clients to be established.

Notification Proxy Agent Having configured and setup the Notification Service server and the clients, it is essential to get the Notification Proxy Agent up and running as well. The Notification Proxy Agent is an application which caches notifications raised in the Engineering application when the Shared Services Notification Service is unavailable. Data change notification will be cached in a queue system until the resumption of the Shared Services server availability. This will then release the information held for downstream consumption. It should be noted that the subscriber might receive the released notifications about 10minutes after the shared services server is made available. The AVEVA Notification Proxy agent is silently installed on the clients’ machine during the installation of the AVEVA Engineering product, or can be installed on its own via an executable file, The installation location will also include an ‘AVEVA.SharedServices.Client.dll.config’ file which will have to be modified as described earlier.


123


Display the selected file and make the changes as demonstrated previously:



The Notification Proxy Agent application installs silently during the installation of the AVEVA Engineering 14.1 product

Finally, ensure that the AVEVA Shared Service Notification Proxy Agent service is started within the client’s machine:

The Notification Services communication links and setup is now complete.


124


5.3

Subscriptions

Having run through the steps as described in the previous sections, the administrator can now create data subscriptions as required. A data subscriber is essentially a client/user who is interested in receiving notifications when data has been modified, created or deleted within project view. Subscriptions are created from within the LEXICON module, and are made up from project Teams and Database View names. Subscriptions are initiated via the ‘Team-View Subscription’ form. This is accessible via the subscription menu button located on the menu bar of the LEXICON application:

Click the ‘Subscriptions’ button on the menu bar of the LEXICON module, and click on the ‘Create TeamView Subscriptions’ menu item. This displays the ‘Team-View Subscriptions’ form.


125


The left pane of the form lists Teams available within the project, whilst the right pane of the form lists available Database Views defined within the current dictionary database. Select and highlight a team on a left pane, then select a Database View on the right pane. Move the selected Database View into the ‘Subscribed views’ pane in the center of the form using the ‘move’ button , and then click the apply button. This will initiate a subscription between the team members (Users) and the data contained within the selected project views.

What this means, is that team members of the selected team who have a view of a list based on a selected Database View will be notified of any data change which occurs on (actioned by another user). For example: A user is a member of a team which has write access to the contents of a DB View for Lines. The user makes a data change to a Line within the line list in an AVEVA Engineering list, and then gets the changes on that line ‘Approved’.



Status change form will display the ‘Reason’ pick list if the UDLOV has been defined for the current status definition


www.aveva.com 126


The changes can only be approved after the approving user receives and reviews the data changes on the object. If satisfied, the approver can then promote the status of the object to an ‘Approved’ status. This issues the object up to the master (Released) databases, as well as triggering a notification to the subscribers. Notifications are received by the subscribers after a ‘Getwork’ has been performed, and in the form of a counter next to a flag icon on the Engineering application. Double clicking on the flag icon displays the ‘Revision Center’ where the items and their data changes are available. The subscriber can chose what changes they will want to bring into their view.



Double clicking on the notification icon displays the ‘Revision Centre’ form, where new or modified engineering items are listed and their changes can be accepted into the users current view


127


In order for this to work correctly, the user will need to have the appropriate Consumer extract databases as part of their current MDB. These databases could be extracts of engineering Master databases which contains items that the current user has no write access to. The consumer extract will help feed the client user/subscriber with the data changes which has occurred in the parent database. The Interdisciplinary Project Data project definition mechanism automatically takes care of the creation and allocation of consumer extracts.



See chapter 3 for configuration and setup of the Interdisciplinary Project Data


128

CHAPTER 6

6

Datasheets

This section gives an overview on the definition of datasheets templates within the AVEVA LEXICON module, required for datasheets creation, data entry and modification functionalities within a datasheet in the AVEVA Engineering 14.1-Tags application. Before Datasheets template can be configured system Administrators are advised to complete the following procedures:   

6.1

Setup attributes and UDETs (Mandatory). Setup distributed schemas for distributed attributes (not mandatory – only setup if required). Setup Database View and Database View Sets (Mandatory – used as data source for datasheets template).

Datasheets Configuration Overview

Datasheets templates are created in AVEVA LEXICON module and stored in dictionary database. The instances are created in AVEVA Engineering, Tags Module and stored in engineering database.

To create datasheets templates and datasheet instances as represented above a number of procedures must be followed such as: In AVEVA LEXICON  Create datasheets template (DSTMPL).  Define datasheets template presentation.  Define Unit of Measure.  Define and assign revision number control to datasheets template.  Add continuation Area (not mandatory – only setup if required). AVEVA Engineering Tags  Create a datasheets instance based on datasheets template created in LEXICON.  Add /modify data in the Datasheets instance.


129


Database Views Set for Datasheets – A Worked Example Although section 4.6.16 covers the definition of Database Views set, as well as its setup and configuration, this is further covered in this section for use within datasheet configuration. The datasheet feature utilises the Database Views sets within its configuration, and this example describes the creation and configuration of a Database Views set which will be subsequently applied. Select the created Database View group ‘MECHANICAL-VIEWS’, and create a ‘Database View Set (DBVWSE) using the context menu.

Fill in the attribute details as shown. Name – PUMP-NOZZLEDBVIEW-SET Description- Database Views Set for Pump and Nozzle User-defined name – PUMP_NOZZLE_DBVIEW_SET

Relevant Database Views can be directly created under a Database View Set or indirectly linked to existing Database Views as illustrated below: To do this, select existing Database View ‘MECH-EQUIPMENT-FULL-VIEW’


130


In the Current Element Editor form, select the “Database View Sets” field browse button and enter the relevant Database View Set name “PUMP_MOTOR_DBVIEW_SET”.

Enter the relevant Database View Set name “/PUMPNOZZLE-DBVIEW-SET”

Select OK button to save the setting

Assign Database View Set “/PUMP-NOZZLE-DBVIEWSET “to NOZZLE-VIEW Database View, using the same procedure shown above.


131


Create Datasheets Template Records – A Worked Example Navigate to the Dictionary World /*, select Create from right-click menu and click on DSTWLD option from the right-click submenu.


132


Enter the following data in the appropriate textboxes: Name: ENGINEERING-DATASHEETS-TEMPLATES Description: DATASHEETS WORLD



These fields are not mandatory.

Navigate to the DSTWLD, select Create from right-click menu and click on DSTGRO option from the rightclick submenu.


133


Enter the following data in the appropriate textboxes: Name: ENGINEERING-DATASHEETS-TEMPLATES-GROUP Description: DATASHEETS-TEMPLATES-GROUP

 

These fields are not mandatory Datasheets Template World (DSTWLD) and Datasheets Template Group (DSTGRO) are the top level containers

Select the created Datasheet Template Group ‘ENGINEERING-DATASHEETS-TEMPLATES-GROUP’, and Create a Datasheet Template (DSTMPL) using the “New Datasheet Template” context menu.

Enter the following data in the appropriate textboxes: Name: CENTRI-PUMP-DATASHEET-TEMPLATE Description: CENTRIFUGAL-PUMP-DATASHEETTEMPLATE


134


Data Source: Select the browse button then displayed.

, next to the Data Source field. The “Add Data Source” dialog is

Select the preferred Database View Set “PUMP-NOZZLE-DBVIEW-SET” from the “View Sets” tab and click on the “Add” button.

Template File: The template file field should remain unset.



The “Template file” field is automatically populated with the location file path of the template when created



Datasheet Templates are stored by default in …….project>dflts\Data\Datasheets\Templates

Click the “OK” button from the “New Datasheet Template” dialog to create the datasheet template (DSTMPL) and close the dialog form.


135


To open the newly created datasheet template, select the datasheet template (DSTMPL) e.g. “CENTRI-PUMP-DATASHEET-TEMPLATE” from right- click submenu click “Edit Datasheet Template”. The Datasheet Template Editor dialog is then displayed.


136


The Datasheet template is divided into two main areas. The left area shows spread sheet layout, this is mainly used to define the datasheet layout. The right area contains a list of all the attributes contained in the selected Database View. After the creation of the datasheets templates (DSTMPL) the presentation or format can then be defined by Administrator in line with the company template format or user preference using the Datasheet Template Editor Toolbar functionalities as shown below: Datasheet Template Editor contains buttons that allow end-users to perform below actions in datasheet template editor.

Icons

Toolbar button

Description

Save datasheet template Print Cut cell

Bold font Italic font Underline font

Allows to save current datasheet template Allows to print current datasheet template Allows to cut data, mapping and presentation of selected cell Allows to copy data, mapping and presentation of selected cell Allows to paste data, mapping and presentation of selected cell Allows to delete data, mapping and presentation of selected cell Allows zoom-in in various sheets in datasheet template Allows zoom-out in various sheets in datasheet template Allows to add continuation area to selected cell area Allows to remove the continuation area available in selected cell area Allows to auto map the cells on right side of selected header text cell Allows to bold font of selected cell Allows to italic font of selected cell Allows to underline the font of selected cell

Font

Allows to change the font of selected cell

Copy cell Paste cell Delete cell Zoom-in Zoom –out Add Area Remove Area Auto Map

Merge/ Unmerge cells Lock Properties Template Explorer Toolbox Message Grid GridLines


Allows to merge or unmerge the selected cell area(s) Allows to lock or unlock the selected cell in datasheet instance Allows to user display or close the Properties window Allows to user display or close the Template Explorer window Allows to user display or close the Toolbox window Allows to user display or close the Message window Allows to user control the display of Grid Lines. This control of the display of Grid Lines is on a per-page basis. www.aveva.com 137


User (s) should be able to design their datasheet templates with different styles of borders and various colours which also reflect in the data sheet instances.

Adding Border to Datasheet Templates Open the borders window by selecting few cells in the datasheet template and right click, and clicking on the new menu item “Border”.

A new window with title “Border Editor” is then displayed.


138


Select the preferred border styles and colours e.g. ‘ThickLine’ style and ‘Black’ colour as shown.

After selecting the line style and colour, click on the Outline, Inside buttons in the “Presets” section, which will be used to set the outer/inside borders of the selected cells.

Users can also select or deselect the individual horizontal or vertical buttons in order to set the cell borders in different ways. After the button selections user can see the over view of the border settings in the “Border” group box. User can also the change the borders by clicking on the “None” button the ‘Presets’ section.

Click on the OK button to display the border in the selected cells. “Cancel” button is used to close the window and user will not see any changes in the borders of selected cells.


139


The Datasheet Editor also allow user to modify Cell properties such as Height and Width, justification of text in Template Editor, font etc. which apply to the whole row or column, when this is selected.



The format of multiple cells can modified, by selecting the desired cells before updating the value in the properties window.

Reference Existing Datasheet Template Excel File Excel files templates from external source can also be referenced and used in existing datasheets template (DSTMPL) configuration.



Only the XLSX file format from MS Excel 2007 & 2010 are supported


140


Reference Existing Datasheet Template Excel File – A Worked Example To do illustrate this, navigate to the preferred DSTMPL (e.g. CENTRI-PUMP-DATASHEET-TEMPLATE); select Properties option from right-click menu to display the “New Datasheet Template” dialog.

From “Template File”, select the browse button , next to the “Template File” field. And select the preferred Excel file from the desired location.

Select the Open button to update the Template File field.


141


Check the “Edit the template when finished” checkbox and click the “OK” button from the “New Datasheet Template” dialog to update the datasheet template (DSTMPL) and open the “Edit Datasheet Template” dialog. The Datasheet Template Editor dialog is then displayed.

Once the datasheet is displayed, Admin users can insert new rows or columns in the Template Editor if required. This can be achieved by selecting the preferred row/columns and click the ‘New’ option to insert new row /column.


142


Database Attribute Mapping to Datasheet Template – A Worked Example To map database attribute (Name) to datasheet cells (Name), drag the required database attribute from the “Field List” (MECH-EQUIPMENT-FULL) section of the Datasheet Template Editor dialog to the desired cell and drop the Database attribute onto the cell.

If the mapping is successful the default yellow feedback colour is displayed.



If the mapping is successful, when the mapped cells are selected, the corresponding attribute will be highlighted in the database source field



If the mapped database attribute datasheet cells have list of values, a pull down list button will be displayed in the mapped cell

To un-map or un-assign a mapped cell, click on the mapped cell in this case “Name” cell and select Delete icon from the Datasheet Template Editor main toolbar or context menu.


143


Using the same procedure as shown above; map the following database attribute from the “Field List” (MECH-EQUIPMENT-FULL) section of the Datasheet Template Editor dialog to the appropriate label text cell: Name Prefix Tag Letter Tag Number Suffix Description Area/Unit

Users can also set the “Behaviour” property of the mapped cell to indicate that the field should be filled in by a supplier when the datasheet instance is exported as an Excel spreadsheet and sent to a supplier to complete some of the information. This can be achieved by selecting the preferred mapped cell in the case “Description”. Click on the Provide By Supplier from the context menu accessible via Behaviour option.


144


The Behaviour field in the Properties window is automatically updated for the selected cell.

For cells that have been set with the Behaviour as Provided by Supplier, these cells will remain unlocked by default, with the rest of the cells in the datasheet instance with the rest cell in datasheet instance being locked by default, when exported as an Excel spreadsheet.

Auto Database Attribute Mapping to Datasheet Template Auto database attribute mapping allows creation and mapping of attributes to the adjacent cell of the selected header text cell. Automap process runs the below algorithm to find the best possible UDA or attribute for selected header text(s). 

Searches the attribute with the same name as of header text in list of data source present in datasheet template



If no attribute exists then, searches the dictionary database for UDA with same name as of header text.



If no match is found, the selected header text row is considered as not matched.


145


Auto Database Attribute Mapping to Datasheet Template – A Worked Example To automatically create and map database attribute to datasheet cells: From the displayed datasheet template, select the preferred header text cells e.g. “Stages & No.Operating”.



In the Datasheet Template it is possible to make multi-selections that include merge cells.

Select the Auto Map

icon from the main toolbar to display the ‘Create and Map’ form.


146


Matched - Selected header text matches the one of the attribute available in template explorer. User can check the detail for matched UDA and can accept the row to create mapping for adjacent cell. User can change the attribute name. Not Matched -Selected header text does not match any attribute in database. User needs to select and specify the required properties to create UDA.Complete the required fields as shown below.

Attribute Name Field – Select the appropriate database attribute name (:NoOperating) from the available pull-down list.



Attribute Names must not contain space. If the label text has equivalent attribute name in the database. Simply modify the displayed attribute e.g. “No.Operating”, should be “NoOperating to remove the space between characters.

Data Source Field – Select the appropriate Data source (database view) e.g. “MECH-EQUIPMENT-FULL”. Data Type Field: Select the appropriate UDA type from the pull-down list e.g. Text. Category Field: UDA Category, this is not required in this example. List of Values: UDA Valid values, this is not required in this example. Unit of Measure: UDA Units; this is not required in this example. This field is only enabled if the UDA type “real” is selected. Maximum Length: Enter the appropriate UDA Length e.g. 50. Select the “Accept” or the “Accept All” to enable the “Create and Map” button.Click the “Create and Map” button to create the label text in the

database as an attribute and map the attribute adjacent cell to the label text.


147


The “Create and Map” form will display message, if the UDA creation fails, successful or required data is not specified by user. The selected label text cells are created in the database and mapped to corresponding label text as shown.

Units of Measure Definitions – Unit Sets The Datasheet Template Editor dialogue gives the Admin user(s) the capability to assign:  

User defined Unit Sets to datasheet Default unit of measure to datasheet

This is explained in the following work examples. The tool also allows the Admin users to set the unit of measure presentation and precision independently from the project units and precision.


148


Unit Sets Definition for Datasheet and List columns – A Worked Example Compound units based on the available base units e.g. m 3/s2, ft3/hours2 can be defined in LEXICON and utilised within Datasheet and AVEVA Engineering Tags List columns. To define desired Unit Sets; Select “Unit Sets” from the main toolbar and then click on “Configure” from the submenu to display the Unit Sets Configuration form.

Enter or select the following data in the appropriate Unit Sets Configuration form textboxes.

Name: Temperature UnitSet Dimension: Select from the pull-down list or enter the appropriate dimension e.g. “Temperature”. Unit: Enter the relevant Units e.g. degC, degF, K. and select enter icon entry.

after each

Add the second Unit Set as shown below, click the ‘New’ button and enter the following details: Name: Pressure Unit Set Dimension: Select from the pull-down list or enter the appropriate dimension e.g. “Pressure”. Unit: Enter the relevant Units e.g. bar, and psi and select enter icon

after each entry.


149




The Unit Set Configuration form supports multiple Unit Sets definitions as shown below



The “New” button is used to create new Unit Sets definitions and “Delete” button to delete existing unit Sets definitions that are not required.

Click the “OK” button from the “Unit Sets Configuration” window to save the configuration and close the dialog.

Assigning Default Unit of Measure to Datasheet Cell – A Worked Example To assign default unit of measure to mapped datasheet template cell with the appropriate unit dimensions. First map the following database attribute from the “Field List” (MECH-EQUIPMENT-FULL) section of the Datasheet Template Editor dialog to the appropriate label text cell. Datasheet Template label text Min Design Pressure Max Design Pressure Max Design Temp Min Design Temp

Database Attributes Minimum Design Pressure Maximum Design Pressure Maximum Design Temperature Minimum Design Temperature

Select the desired cell in this example (e.g.H22).and double click “Unit of Measure” option or drag and drop the “Unit of Measure” option from the Standard Control menu to the desired cell.


150




Datasheet Editor also supports the mapping of Unit of Measure control to multiple cells.

Select the relevant mapped cell in this case “Max Design Pressure” and assign the appropriate “Unit of Measure” (e.g. UoM1-25-8) from the right click menu. The cell Properties is automatically updated with selected Unit of Measure value.

Use the same procedure as shown above; assign the same Units of measure group (e.g. UoM1-25-8) to “Min Design Pressure” mapped cell. Select the pull-down list button from the mapped Unit of Measure cell to display all the associated unit derivatives.


151


To change the “Unit of Measure” Name (e.g. UoM1-25-8) to preferred name. Select the appropriate mapped Unit of Measure cell and enter the desired name, in this case “Pressure” in the “Properties” section of the Datasheet Template Editor dialog.


152


Assigning Unit Sets to Datasheet – A Worked Example Users can also assign a user-defined Unit set to datasheet template mapped cells that has the appropriate unit dimensions, if the user chooses not to use the default unit of measure. To do this; select the desired Unit Sets with appropriate assigned mapped cell. From the Properties window select the preferred Unit Sets definitions from the Unit Sets pull-down list as shown.

Select the pull-down list button from the mapped unit cell to display all the associated unit derivatives.

To set preferred presentation precision if required, click on the Unit of Measure pull-down list button. Click the “Set Precision” tab. The “Set Display Precision” dialog is then displayed.


153


In the “Set Display Precision” dialog, increase the precision value to “3” using the button as highlighted.

In the “Properties” section of the “Datasheet Template Editor” dialog, the Precision Value can also be increase or decrease by entry preferred value in the Precision field.

Select the appropriate Unit Sets definitions from the Unit Sets pull-down list as shown.


154


6.2

Using Standard Controls Operations in Datasheet Template Cells

The Datasheet Template Editor dialog gives users the capability to use the Standard control options such as Check Box, Radio Button List, Picture Box and Free Text Cell in datasheets template if required.

Mapping Checkbox to Datasheet Template Cells – A Worked Example Check Box option is often used in datasheet template, if the desired database attribute to be mapped to the template has database attribute type “logical”. To map a Check Box option to the datasheet template, select the preferred datasheet cell e.g.F18.

From the Standard Control menu double click on the “Check Box” option to assign the “Check Box” to the selected cell as shown:


155


In the “Properties” section of the Datasheet Template Editor dialog. Delete the Caption “Check Box” if is not required.



Datasheet Editor also supports the mapping of ‘CheckBox’ control to multiple cells.

Drag the required database attribute in this case “Schematic Item Link” from the Data Source field to datasheet cells with the “Check Box”. If the mapping is successful the cell will become yellow.


156


Mapping Radio Buttons to Datasheet Template Cells – A Worked Example Radio Button option is often used in datasheet template, if the required database attribute to be mapped to the template have defined list of values. To map a Radio Button option to the datasheet template, select the preferred cell, and then double click on the “Radio Button List” option from the Standard Control menu to assign the “Radio Button List” to the selected cell as shown:

Drag and drop the preferred database attribute in this case “Fluid Phase” from the Data Source field to datasheet cells with the “Radio Button List”.


157




The orientation of the displayed list of values could either be vertical or horizontal. This can be modified via the “Properties” section of the Datasheet Template Editor dialog when the mapped “Radio Button List”. Cell is selected

Mapping Picture Box to Datasheet Template Cells – A Worked Example Picture Box option is used in datasheet template, if user(s) wants to bind a picture file to the database template. To bind picture file to the datasheet template, select the preferred cell. Double click on the “Picture Box” option from the Standard Control menu to assign the “Picture Box” to the selected cell as shown:


158


In the “Properties” section of the Datasheet Template Editor dialog. Click the browse button in the “Image” field and select the preferred picture file:



To display the properties fields of the picture box, the mapped picture box cell must selected

Click on the “Open” tab from the Open File dialog to bind the image to the datasheet template. The bound image size can be re-sized by selecting the preferred size from the “Size Mode” field.



The image URL can also be set to the mapped picture box in datasheet template if required

To replicate the mapped image on every page/sheet of the datasheet template, a ‘Repeating Area’ is added to the mapped image cell using the ‘Add Area’ mechanism as described below:

Select the mapped image cell and click on the Add Area button from the context menu / main toolbar to define the Repeating Area. www.aveva.com © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

159


In the displayed Properties window, select the appropriate Area Type from the available pull-down list, in this case ‘Repeating’

Click on the AssoiciatedSheets field to select the desired page/sheet. In the example select the Sheet2 checkbox and click the OK button to save the settings.



Repeating Area could also be applied if required to free text, mapped cells, Header and Footer.


160


Finally select datasheet template ‘Sheet 2’ to view the Repeating Area.


161


Mapping Free Text Cell to Datasheet Template Cells – A Worked Example Free Text Cell option is used in datasheet template, if user(s) or Administrator wants the cell value to be editable, when datasheet instance is created in AVEVA Engineering (Tags). To map a Free Text Cell to cells in the datasheet template, select the preferred datasheet cell as highlighted:

Double click on the “Free Text Cell” option from the Standard Control menu to assign the “Free Text” to the selected cell as shown:


162




The mapped cell color feedback can be modified by the Administrator if required via the Datasheet Template Setting form accessible via Datasheet menu in Lexicon main toolbar.

Mapping Page Info to Datasheet Template Cells – A Worked Example The Page Information option provides the capability to map page number to datasheet template. The toolbox provides the following properties:



Page Number- Displays the current Datasheet page number in a cell



Total Pages- Displays the total number of Datasheet pages in a cell



CurrentofTotal - Displays the value defined by the Paging Format property, e.g. Paging Format “{0} of {1}” where {0} represents the current page number and {1} the total number of pages

To map to the Page info. Select the “Page Info” control from Standard Controls and then drag and drop onto the cell. (e.g.O5)


163


Then update PageInfo properties to the preferred Paging format.

Complete the PageInfo properties field as shown: Paging Information: From the available pull-down list select Current Of Total option. Paging Format: Enter {0} of 3

Mapping Process Cases to Datasheet Template Cells – A Worked Example In datasheet, Process cases can be represented in two ways:

 

Controlled Cases Cases in Continuation Area

To use the Case functionality appropriate cardinality must be defined for each distributed attributes that may be created. The cardinality defines the number cases the attribute has for each tagged item.



Cardinality definitions, defines the minimum and maximum number of each of the distributed attributes that may be created. A -1 in the maximum definition represent an infinite number

The worked example below illustrates how to map process cases to datasheet template.


164


Mapping Case Control to Datasheet Template Cells - A Worked Example Mapping a Case Control to datasheet template allows user(s) to display process case data and as well as control of the display of governing case data in the datasheet instance if required. To map Case Control, select the Cases control from Standard Controls as shown below. Drag and Drop the Cases control onto a cell, in this example drag and drop it on cell F30.

Right-click on the preferred mapped cell and assign the appropriate the Case Group. In this example assign mapped cell ‘F24-27’ and F31-34 to Case Group (Case-Sheet1-31-6).


165


Select the Control case cell (e.g. GOV Case) to highlights the entire assigned mapped cell. The Case control cell will display the number of cases corresponding to the predefined cardinality definition in the data model once it is assigned to mapped attribute cell with predefined cardinality definition.



6.3

In this example, the predefined cardinality definition in the data model has two values (1, 2) as shown in the displayed pull-down list.

Mapping Continuation Area to Datasheet Template

The Continuation Area functionality allows the user to specify the number of columns and rows that is required per sheet and if the number of objects exceeds the expected number of columns and rows in the datasheet instance the application automatically generates continuation sheets. The “Continuation Area” mapping is not a mandatory, but it is necessary if the number of objects expected in the datasheet instance is unknown. This is mostly applicable to datasheets with Nozzle schedules or Process Cases. Continuation area can be defined in datasheet template to hold the information related to sub-object of datasheet tagged item or Process Cases.


166


Mapping Continuation Area to Cases – A Worked Example Adding Continuation Area to cases in datasheet template, enables the administrators to control the number of displayed cases per sheet/page in datasheet instance.



To add continuation area to cases, select the desired numbers of columns and rows

Then select “Add Area “option from the context menu to assign continuation area to the selected area in the template.


167


When the Continuation Area is added to datasheet cell, an area will be automatically defined in the datasheet template.

Select the mapped continuation area and set its properties. In this example set the Add Area properties as shown below: Area field: From the available pull-down list select Continuous option. Orientation field: From the available pull-down list select Horizontal option. Type field: From the available pull-down list select Cases option.

The case continuation area definition in this example will permit the display of one process case data per sheet in datasheet instance.


168


Mapping Continuation Area to Sublist – A Worked Example Continuation area can be defined in datasheet template to hold the information related to sub-object of datasheet tag. To map sub-object in continuation area, the datasheet template data source (database view) should contain the parent object and child-object (Parent – Child relation) definition. To add continuation area to sub list, select the preferred area in the template.



First map the following database attribute from the “NOZZLE-VIEW” data source section of the Datasheet Template Editor dialog to the appropriate label text cell as shown: Datasheet Template label text Name Description Owner Size



Database Attributes Name Description Owner Bore

Select the preferred area in the template and click on the “Add Area “option from the context menu to define the continuation area.


169


When the Continuation Area is added to datasheet cell, an area will be automatically defined in the datasheet template.

Select the mapped continuation area and set its properties. In this example set the ‘Add Area’ properties as shown below:

Area field: From the available pull-down list select Continuous option. Orientation field: From the available pull-down list select Horizontal option. Type field: From the available pull-down list select SubItems option.

The SubItems continuation area definition in this example will only permit the display of SubItems data in the specified rows e.g. ‘F39-42’ and ‘G39 -42’. However, if the Sublist data exceed the specified rows or columns, a continuation sheet will be created automatically in the datasheet instance to display the remaining SubIltem data.


170


6.4

Mapping Symbols to Datasheet Template

Mapping Symbols to datasheet template label text are often used to indicate the information to be completed either by manufacturer or purchaser in the datasheet instance.

Datasheet Template Editor provides basic four shapes; circle, square, triangle and hexagon accessible via the Toolbox > Symbols window as shown:

6.5

Mapping Symbols to Datasheet Template - A Worked Example

To map a symbol to label text, drag and drop or double the desired symbol to assign the shape to the preferred label text cells. In this example assign the following shapes (circle, square, and triangle) to the label texts as shown.

Once the symbol is assigned the preferred label text cells, the properties of the assigned symbols can be modified using the Properties form as shown.


171


Alignment: [Horizontal/Vertical] – Used to align the symbols/texts. Appearance: Fill State: In this example set text field to Filled via the Properties window. Alternatively click on the assigned symbol to fill the shape.

Lock Fill State: In this example set text field to “False”.



Setting the Fill State to ‘False’ allows the end-user to update the ‘Fill State’ from the datasheet instance.

6.6

Adding Sketch Control to Datasheet Template

The Sketch control mechanism provides the capability to mapping process sketches to datasheet template as well as allowing the end-user to change the process sketches / pictures at the datasheet instance if the picture is defined as editable in datasheet template.

Adding Sketch Control to Datasheet Template – A Worked Example Create a new page/sheet for the process sketches / pictures by selecting the ‘New’ sheet at the end of the datasheet template.

Add the preferred datasheet presentation such as the styles of borders. Modify the cell properties such as www.aveva.com Height and Width, justification of text in Template Editor, font and the sheet name if required. © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

172


Then define the area for the process sketches by merging the desired cells if required.


173


Add a ‘Picture Box’ control by double clicking on the “Picture Box” option or Drag the “Picture Box” option from the Standard Controls menu to the desired cell.

Select the mapped area and set its properties. Click the browse button in the “Image” field and select the preferred picture file.



The image URL can also be used to reference preferred picture file if required.

Set the “Is Editable” field to TRUE to allow the end users update the sketch/image from the datasheet instance if required.

www.aveva.com


174


Select the sketch sheet/page in this case “Sketch Page” to define its properties such as “Sheet Type” and Sheet Type Name.

Sheet Type field: Select “Additional page” from the pull-down list Sheet Type Name field: Select “Sketch Page” from the pull-down list Updating the Sheet Type from Default to “additional page” automatically display a warning dialog. Click on the YES button to continue.

0

Once the sketch control is defined and saved. The application automatically apply the settings to all existing datasheets templates in the project.



Before exiting Datasheet Editor window do remember to save the template in Datasheet Editor Form and “SaveWork” in Lexicon.


175


6.7

Adding Note Page Control to Datasheet Template

The “Note page “control mechanism provides the capability to include Note pages onto the datasheet instance if required.

Adding Note Page Control to Datasheet Template – A Worked Example Create a new page/sheet for the additional ‘Note page’ control by selecting the ‘New’ sheet at the end of the datasheet template. Add the preferred datasheet presentation such as the styles of borders. Modify the cell properties such as Height and Width, justification of text in Template Editor, font and the sheet name if required.

Double click on the “Free Text Cell” option from the Standard Control menu to assign the “Free Text” to the selected cell as shown to make cell value editable, from the datasheet instance.


176


Then select the Note sheet/page in this case “Note Page” to define its properties such as “Sheet Type” and Sheet Type Name.

Sheet Type field: Select “Additional page” from the pull-down list. Sheet Type Name field: Select “Notes Page” from the pull-down list.

Datasheet Revision Control Configuration Datasheets revision control is based on Status definitions and as a result administrator must ensure that there is a preferred status definition that has the datasheet instance element type in its list of controlled element type.

Revision Control configuration setup consist of three parts, this is illustrated below:

  

Revision Number Definition Revision Block Definition Revision Configuration

Datasheet Revision Control Configuration- A Worked Example This worked example illustrates how to create revision elements in the dictionary explorer. To start the creation of revision elements, navigate to the REVCWL ENGINEERINGREVISION-CONFIGURATION).

Select Create from right-click menu and click on REVCGP option from the rightclick submenu.

Enter the following data in the appropriate Current Element Editor Form textboxes as shown: Name: ENGINEERING-DATASHEETREVISION-GROUP © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

www.aveva.com 177




Revision Number Definition

Navigate to the REVCGP Group, select Create from right-click menu and click on REVNOD (Revision Number Definition) option from the right-click submenu to create a REVNOD revision element.

Enter the following data in the appropriate Current Element Editor Form textboxes Name: Revision_Number


178


Select “Edit Revision Block Definition” from right-click menu submenu of the newly created REVNOD (Revision_Number) to display the Revision Number Definition form.

Enter the following data in the appropriate textboxes.

Display Name: Revision Number



The displayed name is a user defined name. Users can enter any desired name Working Revision text: Enter any desired text e.g. *



Working revision text is displayed after the revision number on a non-issued version of a datasheet instance e.g. A1*


179


Number of Parts: Select the number of revision parts e.g. “2”



A revision number can have several parts. Each part is either alphabetic or numeric

Part: Select the revision part number e.g.”1”, Part Name: Enter appropriate Part Name e.g. Major Value type: Set the part number value type e.g. Alphabetic

Part: Select the second revision part number e.g.”2”, Part Name: Enter appropriate Part Name e.g. Minor Value type: Set the part number value type e.g. “Numeric”



Mandatory fields are the display name, working revision text and part names. Part names must be unique. Display names are not checked for uniqueness



If required the ‘Custom’ Value type can be used to set up custom defined sequence of characters. The values can contain letters and digits. Click on the Value ‘Set’ button to display the Custom Value Editor.


180




The Test Revision Number form is shown with sample values from the sequence for each part and the combined revision number. If there are duplicate values it will show a message and highlight duplicate values in red



Revision Block Definition

Navigate to the REVCGP Group (ENGINEERING-DATASHEET-REVISION-GROUP), select Create from right-click menu and click on REVBLD (Revision Block Definition) option from the right-click submenu to create a REVBLD revision element.


181


Enter the following data in the appropriate Current Element Editor Form textboxes Name: Revision_Block

Select “Edit Revision Block Definition” from right-click menu submenu of the newly created “REVBLD” (Revision_Block) to display the Revision Block Definition form.

Enter the following data in the appropriate textboxes Display Name: Revision Block



The Selected Status Definition MUST be different from the one used for the COR definition



The displayed name is a user defined name. Users can enter any desired name.


182


Status definition: Select the appropriate the status definition e.g. (Status Definition for Engineering items).



The datasheet instance element type “DSINST” must be added to status definition list of controlled element type.

Select the “Add attribute” option to add desired attributes to the attribute column and enter preferred name in the “Header” column.



The attributes are derived from information about a status. The attribute drop down contains fields for all states in the selected status definition


183


Click the “OK” button from the “Revision Block Definition” form to save the settings.



Revision Configuration Definition

Navigate to the REVCGP Group (ENGINEERING-DATASHEET-REVISION-GROUP), select Create from right-click menu and click on REVCON (Revision Configuration) option from the right-click submenu to create a REVCON revision element.

Enter the following data in the appropriate Current Element Editor form textboxes Name: Revision_Configuration


184


Select “Edit Revision Block Definition” from right-click menu submenu of the newly created REVCON (Revision Configuration) option.

Display Name: Revision Configuration for Datasheet



The displayed name is a user defined name. Users can enter any desired name

Element type: Select the datasheets element type “DSINST” via the ellipsis button.


185


Status definition: Select the appropriate Status definition from the pull-down list e.g. “Status Definition for engineering items (Datasheets)”. Associated revision block definition will automatically be displayed.

Create working revision at: Select the appropriate Status definition value from the pull-down list e.g. “Working”.

Issue revision at: Select the appropriate Status definition value from the pull-down list e.g. “Approved”.

Revision number definitions: Select the appropriate Revision number definition from the pull-down list e.g. “Revision Block”.

Revision block definitions: Revision number definition checkbox must be selected.



The Selected Status Definition MUST be different from the one used for the COR definition



The Revision block definitions are optional, but should be selected for any configuration that uses them. The Datasheets application will list the selected revision blocks in the datasheet template explorer

Click the “OK” button from the Revision Configuration form to save the settings. Once the revision configurations are completed, the administrator must link the revision configuration to the datasheet template using the “Datasheet Template Settings” form as shown.



The “Bound Cell Colour” field is used to set the Mapped cell colour feedback in Datasheet template.



The “Free Text Cell Colour” is used to modify or set preferred free text cell colour feedback in Datasheet template.



The “UDA Setting Owner” field is used to modify or set preferred User defined attribute group. This is only applicable if auto database attribute creation is in use.


186




The “UDA Setting Default Type” field is used to modify or set preferred UDA type. This is only applicable if auto database attribute creation is in use

Click the “OK” button from the Revision Configuration form to save the settings.

Revision Control in Datasheets uses Status transitions UI, based on the current selection in a Tags list and as result a Tags Database View based on datasheet instance elements must be created as shown below:

The Database View should contain the following Attribute columns (ATTCOL) in the Database View as shown.

Mapping Revision Block and Mark to Datasheet Template Revision block is a block which defines the number of column and row to be displayed in relation to revision in datasheet. Revision block can be mapped to cell by:

 

Clicking on the desired revision block in the template explorer and then drag and drop onto cell. Selecting the cell and double click on the desired revision block in template explorer.


187


Revision Block and Mark Mapping to Datasheet Template – A Worked Example To map a revision block to datasheet template, Open the desired datasheet template as shown:



Select the datasheet template (DSTMPL) e.g. “CENTRI-PUMP-DATASHEET-TEMPLATE” from rightclick submenu click “Edit Datasheet Template

Click on the desired revision block in the template explorer and then drag and drop onto the cell as shown:


188


When a revision block is mapped to datasheet cell, an area will be automatically defined in the datasheet template to hold the defined data in the revision block. A revision block mapped cell needs to have the required area on right and bottom to accommodate the revision block/area.

To map “Revision mark” to datasheet template: Click on the “Revision Mark” in the template explorer and then drag and drop onto desired cell.

Alternatively, select the preferred cell and double click on the desired “Revision Mark” in Template Explorer.



“Revision Mark” are generated by the System, they are not manually configured


189


Exercise 8 – Datasheet Configuration 1. Create a new Reciprocating Pump datasheet template (DSTMPL) as shown.

Name Field: Enter “Reciprocating_Pump” Description: Enter “Datasheet Template for Reciprocating Pump” Data Source: Select from the Add Data Source Form “PUMP-NOZZLE-DBVIEW-SET_” Template File: Browse to the excel file “Reciprocating datesheet.xls” located in tradflts\Data\Datasheets\Templates folder.

2. Defined preferred Revision control configuration for the datasheet template as shown.

(a) Revision Number


190


(b) Revision Block

(c)

Assign appropriate Revision block to existing Revision Configuration (Revision_Configuration)


191


3. Defined preferred Unit Sets for the datasheet template as shown.

4. Open the datasheet template “Reciprocating Pump” (“Reciprocating_Pump”) (a.) (b.) (c.) (d.)

Assign or map database attributes to the datasheets template using Auto mapping. Assign defined Units of Measure (Unit Sets) to the datasheets template. Assign defined of Revision to datasheets template. Add continuation Area to the datasheets template.


192

CHAPTER 7 7

Project Explorer Configuration

The engineering Project explorer is a configerable user interface based on the AVEVA Flexible explorer tool. This interface allows for the presentation of engineering items structured according to functional locations or any other user defined structure formats. These structure formats are displayed in a hierarchical form within the AVEVA Engineering Tags application. Each structure is based on a template which is also defined as a ‘Root Node’. Further nodes can be built beneath the root node. Templates and their contents are represented as individual hierarchies within the Project Explorer. Every template is configured to be primarily based on a type of data, e.g. Systems, Classes, and Documents or as a Project BreakDown Structure (PBS). Unlike a conventional tree view explorer, the Project explorer has a dynamically active hierarchical structure. This means that the location of items will be dependent on the current set criteria and attribute values. The Project explorer is fully configurable and setup within the LEXICON module as well is demonstrated in this chapter.


193


7.1

Configuring the Flexible Explorer - A Worked Example

Using the Flexible explorer tool the Project Explorer can be configured according to the LEXICON elements structure shown:

Each block on the diagram is defined as shown:

PBSWLD

PBS Templates world: The top-level administrative element,w hich holds the PBS Templates.

PBS Template Definition: PBSTPL

This is a definition of separate hierarchy structure , and is presented as a single root node

PBS Object Node: PBSOBN

Used to define the generation of a set of nodes at the hierarchical level it is placed. The nodes and their inherenct members will will be dynamically updated when the attributes or criteria of related database objects are modified

PBS Text Node: PBSTXN

This is simply a generating node, and does not represent any database object. But they can contain PBSOBNs

PBS Criteria: PBSCRT



This element is used to position resulting nodes below appropriate/required parent nodes

The demonstration in the following examples covers the creation and definition of the dictionary elements for a demo project explorer. This explorer will be developed and structured to display hierarchies for a Project BreakDown structure (PBS), System, Document and Class Based Structure as displayed in the opening screenshot

www.aveva.com


194


Creating a PBS world (PBSWLD) 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’ > ‘PBSWLD: PBS Templates World’ entry, to create a PBS Templates world.

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

Creating a PBS template (PBSTPL)

Select the created PBS World, display the context menu and click ‘Create’ > ‘PBSTPL: PBS Template Definition’ to create PBS Template definition.

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

The ‘PBS text’ entry specifies the text to be displayed on the created template, like a node name. This is set to ‘Project BreakDown Structure (PBS)’.


195


‘PBS Sorting’ entry specifies the order in which items generated from nodes beneath the root node/template will be placed. This is set to ‘Natural Alpha Numeric’, which is selected from the pick list. Hence items with node texts which begin with higher alphabets will be listed first before lower alphabets etc. A user defined context menu can be referenced and setup for the template node with the ‘PBS context menu’. This could be extracted from a method within a pml function using the ‘Flexible Explorer Editor form.



A further example of this function will be demonstrated later in this chapter

Each node and items on the Flexible Explorer interface can have an icon displayed next to its text. The ‘PBS icon’ entry specifies what icon is to be displayed by typing in the icons name (as this must already exist in the Shared Resources location) or can be derived with a PML 1 expression.

This will be left blank, which will have the icon representing the object displayed.

From the created PBS World, and PBS Template, the resulting explorer hierarchy will be displayed within the Engineering Tags application as shown:



The user will have to log into the engineering tags application and click the Project Explorer button to display the Project Explorer. If the explorer user interface is already being displayed, then running a ‘get work’ updates the contents of the explorer with changes from the LEXICON module


196


Creating a PBS Object (PBSOBN)

Select the created PBS Template, display the context menu and click ‘Create’ > ‘PBSOBN: PBS Object Node’ to create PBS Object Node.

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

The ‘PBS text’ entry is specified by an expression which combines the full name (FLNN) and the description (desc) value of a resulting object separated by a dash ( - ), in order to derive the display text (node name) of the objects. The selection of a ‘PBS formula type’ entry determines the kind of formula which is used to derive the objects to be listed in the explorer (resulting nodes). Select the ‘PML expression’ entry from the pick list. The ‘PBS formula’ entry is a text attribute whose entered values is dependent on the formula type selected. Type in: ‘Collect all sysgrp’. This will fetch all available SYSGRP objects available in databases within the current MDB. ‘PBS Sorting’ entry is set to ‘Same as on Parent’. Resulting nodes will be ordered using the same selection that was selected for the owning PBSOBN element (Natural Alpha Numeric). From the created PBS object, the resulting explorer hierarchy will be displayed within the Engineering Tags application as shown:


197


Creating a PBS Text Node (PBSTXN)

Select the created PBS Object, display the context menu and click ‘Create’ > ‘PBSTXN: PBS Text Node’ to create PBS Text Node.

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

‘PBS formula type’ entry is set to ‘PML function’ as this specifies that the following PBS formula entry will be a global variable which points to a pml function within the pml library. Enter: ‘!!getAreasForSystemACE()’



The pml functions will be made available along with the copy of the supplied ACE project utilised for this training

The PBS formula can be entered using the ‘Flexible Explorer formula editor’ form


198


The entered formula reads and deploys the methods contained within the referenced PML function. This particular function is designed to generate a node which will be based on the Area numbers of engineering items (ENGITE). So this will create a folder in the explorer hierarchy which will be named after the area number which is shared by objects it contains. This means that when an object is created, it will be grouped by area numbers in this node. The FlexibleExplorer formula editor is also used to make the entered pml function apply to every object generated by the PBSOBN created earlier. This is done by dynamically entering the reference number of the PBSOBN as an argument in the command: Place the cursor inside the parenthesis ( | ) and then click the ‘Insert parameter’ link label, then select the entry as shown:

This will dynamically place the DB refno of the selected item as an argument within the function being called



The element DBref selected is the PBSOBN which was created earlier


199


Create another PBS text node (PBSTXN) which will generate a node to group and hold items according to their element types. Its behaviour and node name will be derived from the pml function within the PBS formula, which it references. Within the Current Element Editor, fill in the attribute details of the created PBSTXN as shown.

‘PBS formula type’ entry is set to ‘PML function’. For the PBS formula entry, Enter: ‘!!getEngineeringClassesACE()’.

Create another PBS object node (PBSOBN) which will generate a node to group and hold items according to their element types. Its behaviour and node name will be derived from the pml function within the PBS formula, which it references. Within the Current Element Editor, fill in the attribute details of the created PBSTXN as shown.

This created PBS Object node will generate the database object (Engineering item), which will be located and grouped beneath the higher elements in the hierarchy of the structure. The objects generated will display their full names (FLNN). ‘PBS formula type’ entry is set to ‘PML function’. For the PBS formula entry, use the FlexibleExplorer formula editor form as shown:


200


The formula indicates that the objects to be generated will be an item(s) whose element type is derived from the parameter (the owning PBSTXN), and will be stored within that node. Another condition will be that the item(s) will be located within a generated node based on its area number.

DBref of 1st parameter (Area Number)

DBref of 2nd parameter (Element Type)

‘PBS context menu’ ensures that the resulting objects will be able to display a context menu when they are selected and right clicked. The contents/entries of the context menu are obtained from a default xml files which are located in the installation directory of the Administration product. This is set as AVEVA.PBS.TAGS_Element_’ + TYPE + ‘.Menu’. Finally any resulting/derived engineering object will be further grouped within a special node which is based on a user defined attribute :SPECIFICATION. This is entered within the ‘PBS group by’, which is a text entry.

From the created PBS elements, the resulting explorer hierarchy will be displayed within the Engineering Tags application as shown:



In the example screenshot shown, the Lines derived are grouped within nodes based on the :SPECIFICATION attributes, which in turn are grouped within a node for the element types, which in turn are grouped within a node based on the area number and then the System

 The referenced pml functions are also configured to still create a node even when containing nodes evaluate successfully. This means that we can have for example ‘Unset Area’ node


201




The context menu expression for the last PBSOBN references an xml file which contains instructions on the menu entries and behaviour. This allows the context menu to be visible when displayed from the derived object as shown. The file whose contents are being referenced is the ‘TagAddins.xml’ file, which resides in the installation location of the AVEVA Engineering product

In the cases where the PBS formula of the first PBS object node (PBSOBN) does not evaluate successfully (i.e. from the example, the engineering object has no System (SYSGRP) attribute specified) then a node can be setup and configured to hold such unassigned items. A new PBS text node is created to derive and hold items which have no System (SYSGRP) attributes, as shown: Select the created PBS-TEMPLATE, display the context menu and click ‘Create’ > ‘PBSTXN: PBS Text Node’ to create a new PBS Text Node. Within the Current Element Editor, fill in the attribute details of the created PBSTXN as shown.

‘PBS formula type’ entry is set to ‘PML function’. For the PBS formula entry, Enter: ‘!!getUnassignedItemsNode()’. The referenced pml function will enable items which are not assigned with a System (SYSGRP) to be created within this node, instead of the nodes created earlier.

Create further PBS text node (PBSTXN) and PBS object node (PBSOBN) which is similar to those created and described earlier as shown:


202


The flexible explorer elements are defined to be similar to those which were configured earlier, but the top element is defined to hold the so called ‘Unassigned items’ (items without a system attribute (SYSGRP). So when engineering item is created and it has no system (SYSGRP) attribute, then it will be located within the ‘Unassigned items’ node.


203


Creating a PBS criteria Node (PBSCRT) The PBS criteria element ensures that a given node fits to a specific parent hierarchy. This means that when items are created, the criteria element will help determine enforce the placement of these items within the appropriate node.

Select the last created (Within the PBS-TEMPLATE) PBS Object, display the context menu and click ‘Create’ > ‘PBSCRT: PBS Criteria’ to create a PBS Criteria.

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

The PBS criteria must be created beneath the item for which the location checks will have to be made. Hence in the example shown, the PBSCRT was created beneath the PBSOBN which generates the engineering items. PBS query node allows for the selection of the appropriate node in which the location checks will be made. So in the case shown, the PBS query node was selected as the top level PBS element, the PBSTEMPLATE created earlier. This means that items created will be checked for storage within the PBSTEMPLATE node only. Hence this selection is made from the pick list as shown.


204


Element Member items Further PBS Text nodes and Object nodes can be configured to cater for member elements of items which can be seen as parent object. For example, the Flexible explorer can be configured to display available nozzles beneath equipment. Select the last created (Within the PBS-TEMPLATE) PBS Object, display the context menu and click ‘Create’ > ‘PBSTXN: PBS Text Node’ to create a PBS Text Node. Within the Current Element Editor, fill in the attribute details of the created PBSTXN as shown.

The ‘PBS Formula’ is configured to evaluate on items which are generated by its owning PBS object node (PBSOBN). This is referenced as a parameter using the FlexibleExplorer Formula Editor to insert the parameter

DBref of parameter

The methods within the referenced pml function will evaluate the items generated by the PBS object to identify items which have member elements which are valid and exist. A PBS object PBSOBN will be created which will generate/derive existing member items.


205


Select the last created PBS text node, display the context menu and click ‘Create’ > ‘PBSOBN: PBS Object Node’ to create a PBS Object Node. Within the Current Element Editor, fill in the attribute details of the created PBSOBN as shown.

The member elements are configured to display right click context menu as appropriate, and the contents and menu entries will be extracted from an XML file located within the AVEVA Administration product installation using the expression as shown in the PBS Context menu entry.

Grouping elements by class (Attributes) Derived elements displayed in the Flexible explorer can be configured to be grouped within classes, or any required attributes. Multiple instances of the object nodes can be created and configured to hold items which share a common class or attribute value.

Select the PBS Object (for the generation of the parent elements), display the context menu and copy. Paste 4 instances of this object under the same owning element, and modify the ‘PBS group by’ entries as shown

This will copy the PBS object node (configured to derive and display the main engineering elements in the Flexible explorer) as well as its children elements, and create instances of them which can then be individually modified as shown:


206




Paste 4 instances of the copied PBS Object Node (PBSOBN)

The ‘PBS group by ‘ values are modified to allow for the class grouping of engineering items which are Equipment, Valves, Lines, Instrument and Instrument Loop. The grouping could be done by any valid attribute, but it should be noted that each template should hold no more than 1 grouping attribute per Node. Modifications will also need to be made on each PBS formula expression entry, so as they reference the correct parameters. Enter ‘:EquiClass’ in the ‘PBS group by’ to group Equipment items by :EquiClass attribute. Modify PBS Formula as shown:

Enter ‘:InstClassDesc’ in the ‘PBS group by’ to group Instrument items by :InstclassDesc attribute. Modify PBS Formula as shown:


207


Enter ‘:LoopClassDesc’ in the ‘PBS group by’ to group Instrument Loops by :LoopClassDesc attribute. Modify PBS Formula as shown:

Enter ‘:VALVETYPE’ in the ‘PBS group by’ to group Valves by :VALVETYPE attribute. Modify PBS Formula as shown:



Engineering items will now have individual groupings according to the defined class/attributes. For example Equipment can be grouped within equipment class items like ‘Pump’, ‘Vessel’ etc.



Valid and available member elements are visible beneath items which are based on parent objects. For example, the Pumps have Sub Items which are Nozzles


208


The previously described configuration is performed for the ‘Unassigned items’ node:


209


7.2

Document Template for the Flexible Explorer - A Worked Example

The Flexible Explorer can also be configured to display document items (non database items) within is owns dedicated template structure. Following on from the previous section, PBS templates will be created for the display of datasheets, Diagrams, and Engineering lists elements. Afterwards relevant PBS object nodes and PBS text nodes will be created and defined for each template.

Creating an Object Node for Datasheets Select the created PBS World, display the context menu and click ‘Create’ > ‘PBSTPL: PBS Template Definition’ to create PBS Template definition for Documents. Within the Current Element Editor, fill in the attribute details of the created PBSTPL as shown.

This creates a new hierarchy element for ‘Documents’ on the Flexible explorer user interface.

Select the created PBS Template, display the context menu and click ‘Create’ > ‘PBSTXN: PBS Text node’ to create PBS Text node for Datasheets. Within the Current Element Editor, fill in the attribute details of the created PBSTXN as shown.


210


This is a node which acts as a static container to hold datasheet items (DSINST) as they are created.

Select the created PBS text node, display the context menu and click ‘Create’ > ‘PBSTXN: PBS Text node’ to create PBS Text node. Within the Current Element Editor, fill in the attribute details of the created PBSTXN as shown.

‘PBS formula type’ entry is set to ‘PML function’. For the PBS formula entry, Enter: ‘!!getEngineeringClassesACE()’. This node allows for the generation of items which are of the type ENGITE.

Select the created PBS text node, display the context menu and click ‘Create’ > ‘PBSOBN: PBS Object node’ to create PBS Object node. Within the Current Element Editor, fill in the attribute details of the created PBSOBN as shown.

This node allows for the generation of datasheets from available engineering items. This uses an expression which references a pml function to extract the datasheet instances from the engineering items derived in the PBSTXN previously created. It also carries a reference for a context menu for datasheet items on the Flexible explorer.


211


Creating an Object Node for Diagrams Select the created PBS Template, display the context menu and click ‘Create’ > ‘PBSTXN: PBS Text node’ to create PBS Text node for Datasheets. Within the Current Element Editor, fill in the attribute details of the created PBSTXN as shown.

This is a node which acts as a static container to hold diagrams/P&IDs items as they are derived. It carries the display name: ‘Drawings’


This is a node which acts as a static container to hold diagrams/P&IDs items as they are derived. It carries the display name ‘P&IDs’.


212


Select the created PBS text node, display the context menu and click ‘Create’ > ‘PBSOBN: PBS Object node’ to create PBS Object node. Within the Current Element Editor, fill in the attribute details of the created PBSOBN as shown.

‘PBS formula type’ entry is set to ‘PML expression’. For the PBS formula entry, Enter: ‘collect all scdiag’.

This node allows for the derivation of diagrams/P&IDs which are based on the SCDiag element type. It also carries a reference for a context menu for datasheet items on the Project explorer. Available diagrams in a schematic database within the current MDB will be displayed in the Project explorer.



The diagram context menu entry allows for the display of the diagram on its own viewer within the Engineering Tags application


213


Creating an Object Node for Engineering Lists Select the created PBS Template, display the context menu and click ‘Create’ > ‘PBSTXN: PBS Text node’ to create PBS Text node for Engineering Lists. Within the Current Element Editor, fill in the attribute details of the created PBSTXN as shown.

This is a node which acts as a static container to hold Engineering Lists as they are derived. It carries the display name ‘Engineering Lists’.


This is a node which acts as a static container to hold Categories as they are derived. It carries the display name ‘Categories’


214



‘PBS formula type’ entry is set to ‘PML function’. For the PBS formula entry, Enter: ‘!!getCategories()’.

This node allows for the derivation of engineering categories in which engineering lists are created. The expression references a pml function which contains the derivations syntax for available categories.



215


This node allows for the derivation of lists. The expression references a pml function which contains the derivations syntax for lists within available referenced categories parameters. It also carries a reference for a context menu for datasheet items on the Flexible explorer.

Exercise 9 1. Recreate the Flexible explorer configuration as demonstrated and displayed (This might require the deletion of the items created during the examples). Refer to the supplied demo ‘ACE’ project for examples.


216

CHAPTER 8 8

Database Views Editor

The Database Views Editor is a General user interface for the creation definition and modification of Database Views in a quick and user friendly manner. Although Database Views can be fully defined and configured within the LEXICON module, the Database Views Editor provides an easy access and manipulation of a collection of these Database Views and their configuration as well allows for their creation, deletion and update. The Database Views editor user interface sits in both the LEXICON and Tags Modules, as they can be utilised from both applications, although there are Subtle differences between how they can be used.



A Database View is the presentation of an element type or UDET with a listing of its attributes or a selection of its attributes, structured to allow the creation of objects and attribute values beneath


217


The Database Views Editor User interface in the modules mentioned are one and the same, except in the Tags Module where it carries a representation of a ‘closed’ lock when the ‘Project Views’ ‘View Definition Set’ is selected.

This is not the case for the Database View Editor within the LEXICON Module where it is represented as ‘Open’. This signifies that edits to the views contained in the ‘Project Views’ can only be made within the LEXICON module, and not the Tags module. A Definition set are areas where the Database Views are created and placed, as well as modified and updated. These Definition sets include:    

Element View – Database Views defined automatically to represent the database hierarchy, and includes all available element types within the MDB utilised. Project Views – Database Views defined in the dictionary database for a project. User Views – Database Views defined as a file in the users project setting A User defined Definition Set

These Definition sets are only visible and manageable from within the Database Views Editor as will be shown later in this guide.



The Database Views Editor in both the LEXICON and Tags modules carry the ‘Closed’ lock when the ‘Element views’ definition set is selected, as no edits to the DB views contained within are permitted in both modules



Within the Tags module, the Database Views Editor can be reached through ‘Admin -> DB View Editor’. The Admin tab will be available for system/Admin users with the appropriate access to the module



Database Views were originally configured from the dictionary explorer of the LEXICON module, as shown here. These views can now be created and edited using the Database Views Editor

Refer to Section 4.6 for details on setting up a Database View within the LEXICON module


218


8.1

Sample DB Views and View set

On the Database Views Editor, select the ‘Element Views’ from the ‘View Definition Set’ drop down list, and select the ‘All’ entry from the ‘Database Types Filter’ to display views of all database element types available to project session being run.

Select ‘Project Views’ view definition set, and then select the ‘Engineering’ database type filter, to display all DB views defined in the LEXICON module, which are based on engineering UDETs or distributed UDETs.

With the ‘Project Views’ view definition set, filter on the database type ‘All’. This displays all DB views defined in the LEXICON module which are based on any UDET. Select the ‘View Sets’ tab. This displays collections of sample DB views, which have been sorted according to the database type which the relevant items will be located. These collections are known as ‘View sets’, which is a collection of Database Views bunched together for a similar purpose. The collections can be based on any required criteria.


219


A View Set can be compiled by copying existing DB views (using its context menu) and ‘paste’ within any existing view set, as will be shown.

8.2

Defining a Database View

With the DB views editor within the Tags module, DB views can only be defined or modified within the ‘User Views’ view definition set, or within a user defined view definition set. Database Views defined within the ‘User Views’ view definition set are stored in an xml file format located in a default location as shown for the ACE project below:

The following example will describe the definition of DB views for a Line element type and selected attributes, as well as DB views for its disciplines and selected attributes appended to them.

Refer to Section 4.6 for details on setting up a Database View within the LEXICON module and definition www.aveva.com of utilised terminology © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

220


Defining a Database View – Single Sourced Data Log into the Engineering application of the ACE Project, using the ‘Username: SYSTEM’, ‘MDB: ADMINLEXICON’. Click on the ‘Admin’ tab and click on ‘DB View Editor’ menu button to display the DB view editor.. Select the ‘User Views’ view definition set from the drop down list. This should be displayed with an empty ‘view’ area.

Place the cursor on the empty area, and display the right click context menu. Select the New > View entries, to create a new Database View.

A new DB view is created and is initially named ‘Table 2’ by default.

Fill in the property details as shown, ensuring to type in the correct element type or make a selection with the available browse button. © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

www.aveva.com 221


This DB view will be based on the :LINE element type. Select the ‘Data Source’ tab in the ‘View Detail’ pane. Select the Allow row creation checkbox, as this will allow row items to be created on any grid/list which is based on this dbview. Leave the ‘Auto assign or create owner’ checkbox unchecked, so as LineTag items will be stored in a location which will be specified in the Owner Expression. For the Owner Expression, type in the texts: (id /PipeLine ). This will be the name of the ENGGRP (engineering group) where the Line items will be stored when they are created in the dbview based list.

The ‘Type Expression’ is left unset, as it specifies the ‘ActType’ attribute of the item to be created. But this is not required as the element type being used can be dynamically derived. Select the ‘Columns’ tab, and configure the attribute columns which are required for the dbview. Click on the ‘New’ icon to create a new row (which represents a column). Select the Data source, attributes and Description as shown.


222


The ‘Column name’ acts as a column header / caption, and can have texts typed into it. Selecting the ‘Read only’ checkbox, will ensure that the column will not be editable, and will appear greyed out.



Attribute/Expression entries are selected from a pick list

Select the ‘Preview’ tab, to view how the columns will be displayed.

The list above is populated with values as the ACE project already contains Line items, and values against available attributes. This Preview will be displayed with just the column headings and no values if this were a fresh project.



The ‘:Duty’ column has its entries greyed out, as it is a ‘Read only’ column as specified in the ‘Column’ tab



This function is only available on the Database Editor initiated from within the Engineering application. Or else, the Preview grid is not populated with any data ‘

Return back to the ‘Column’ tab, and include more rows of attributes as shown.


223


Run a ‘Save Work’ Create a new list which is based on the created Dbview from the ‘Manage button’ in the home tab. See (AVEVA Engineering – Tags (Basic) for setting up and displaying a list Create a new LineTag item ‘LineA’, and fill in the attribute details. Observe the creation of the item in both the list view and in the correct location within the database explorer.


224


Defining a Database View – Multiple Sourced Data Next, define a Dbview for Line items and its attributes, of which 2 are owned by other disciplines. For this example, a new user defined View Definition Set will be created and utilised. In the ‘View Definition Set’ group of the Database Views Editor, click on the ‘New’ icon, to display the ‘Create Definition Set’ form.

This user defined View Definition Set is saved as an xml file in any location of the workstation used and can be moved or emailed off.

Create a new DB view as was previously done, by right clicking on the empty ‘Views’ pane, and selecting the entries: New > View. Or the previously created db view ‘LineTag DB View’ can be copied from the ‘User Views’ view definition set, and pasted into the newly created view definition set. From the ‘User Views’ view definition set, copy the ‘LINE-BASIC-VIEW’ and paste this in the View Definition Set for ‘Set of Training DBViews’.


225


This pasted view will initially be named ‘Table2’ on the ‘views’ table. Using the ‘Rename’ command on the context menu, change the name to ‘Line+Discipline Data view’.

Update the Description.

Select the ‘Data Sources’ tab, then expand and configure an attribute rule for the ‘Creation Rules’ This creation rule will ensure that each time a new item is created, the conditions of the rules must first be met.


226


Click on the ‘Add Rule’ button to include an attribute rule, and fill as shown.

This simple attribute rule ensures a request for the definition of a Name as an initial step (Create Element information form) when a Line item is being created. The rest of the details remain unchanged. Click on the listed Dbview, and select the ‘’New SRCELEMENT’ from the context menu to create a source element entry

The ‘source element’ will point to a relevant element type whose attributes will be utilised in attribute columns. The ‘Line Process Data’ and ‘Line Piping Data’ have been modelled as distributed UDETs, which are based on the XPITEM Base type, and have specific sets of attributes assigned to them. These distributed UDETs carry the user defined names :PROCESS-DATA, and :PIPING-DATA respectively. They have both been nominated as distributed members of the :LINE element type. Enter the descriptions and expressions as shown


227


Select the ‘Columns’ tab to display the previously defined attribute columns for the :LINE element type, then add new rows for attribute columns specific to the defined source elements ensuring to select the appropriate data source from the drop down list as shown:

Select the ‘Line Process Data’ entry as the source data of the attribute to be defined in the new row, then select the required :PROCESS DATA attributes.

www.aveva.com


228


Define the rest of the attribute columns as shown

It is possible to populate the Dbview with attribute columns for all available attributes of a selected data source, by clicking on the ‘Add Standard Attributes’. This triggers an automated action which defines new attribute columns for each available attribute. Click on the ‘Add Status Column’ text button to include an attribute column for the Status of the item, then select a required attribute qualifier, as shown.


229


Run a ‘SaveWork’ and preview the defined attribute columns. Create and display a list view based on this new DB view.



When creating the new List, ensure that the correct Definition set is selected

The list shown carries the selected attributes for the LineTag, and the distributed data for both the Line process data and Line stress data. The column grouping shown is a user defined layout. Create a new LineTag item for a new row, and observe the ‘Create Element Information’ form displayed. This form carries the required condition which was defined in the ‘Attribute rules’ (in the Creation rules section of ‘Data Sources’ for the DB view). A new LineTag item will not be created until the required attribute of ‘Name’ is supplied. © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

www.aveva.com 230


Type in the text ‘LineB’ in the Name entry, and click the ‘OK’ button.

Save the view definition set, using the save icon to preserve the created Dbview and its configuration.



For each new session of the Tags module, user defined view definition sets will need to be ‘Opened’ using the

icon to reload the Db views from the xml file


231


Defining a ‘View Set’ As described earlier, a ‘View Set’ is a collection of DB views, which are sorted and placed according to any required criteria. Select the ‘View Sets’ tab, and create 4 new view sets with the context menu and rename as shown.

Select the ‘User Views’ definition set, and copy the ‘LINE-BASIC-VIEW’ which was created earlier.


232


Select the ‘Line items views’ set in the ‘View Set’ section of the user defined view definition set (Set of Training DbViews), and Paste the copied ‘LINE-BASIC-VIEW’ using the context menu then rename the default name of ‘Table2’ to an appropriate name which has not been used before (LINE-BASIC-VIEW2) and hit the icon.

The addition of this DB view to the set, has also created a copy of this DB view on the ‘Views’ section.

Select the ‘Project Views’ definition set, filter on the Engineering database, and copy 2 DB views for each of these element types :EQUIPMENT, :LINE, and :INSTRUMENT. Then paste each copied DB view beneath the relevant view set in the ‘Set of Training DBViews’. Finally, have them renamed as shown:


233



234




Each copied DB View will need to be renamed differently from its original name when it was copied



The addition of a DB View to a View Set, also creates a copy of that DB View on the ‘Views’ section of the definition set

Exercise 10 1. Create a user defined view definition set with the name ‘Definition set for Training’ 2. Save this definition set in suitable location on your machine 3. Create a new Database View with the right click context menu, with the name ‘Mechanical DBViews’ and description 4. Assign the element type :EQUIPMENT to the newly created Mechanical DBViews 5. Include the owner expression ( id /MechanicalItems ) or any preferred database location, allow row creation 6. Create attribute columns for Name, Description, Tag number, Tag Letter,and model number 7. Preview the created DB View, and generate a list based on the view. 8. Create a new DB View for ‘Mechanical items and Distributed data’, with the :EQUIPMENT element type, and an appropriate description 9. Include an owner expression and an attribute rule 10. Include a ‘Source Element’ with the description ‘Mechanical data’, and expression ‘XRQELE( typename :MECHANICAL-DATA )’ 11. Include attribute columns for both the Mechanical items and source elements 12. Preview the DB view, and generate a list based on this new DB. 13. Create View sets as shown in the example above. 14. Save the view definition sets


235



236

CHAPTER 9

9

AutoNaming Engineering items

AutoNaming allows for automated / dynamic selection of appropriate names for engineering items when they are created or renamed. These names can be in a sequential format, can be placed in several patterns and are rule based.

9.1

The AutoNaming Feature

Within the Tags module, the AutoNaming feature can be reached from the ‘Admin’ tab.

Click on the ‘AutoNaming Setup’ button to display the ‘Naming Settings’ form which allows for controlling the use of the AutoNaming function in a session.

AutoNaming actions can be switched On or Off with the ‘Auto Naming On/Off’ checkbox, and AutoNaming rules can be managed through the ‘Define Naming Rules’ button. The ‘Naming Mode’ group allows for the selection of required behaviours for sequential indexed naming. ‘Infill’ indicates that the any available index number will be used to name an element. ‘Append’ indicates that elements will be named using increasing index numbers. The ‘Load’ and ‘Save’ buttons are utilised when defined name rules are to be saved or loaded from the Naming rules file.



The user will need to be an ADMIN user, or a member of the Tags ADMIN team, in order to view and access the Admin tab



The use of ‘Auto Naming’ Rules configuration overrides any existing ‘Creation Rules’ already in place.


237


9.2

AutoNaming Configuration setup

On the ‘Naming Settings’ form, ‘Click on the ‘Define Naming Rules’ label button to display the ‘Naming Rules’ form.

This form allows for the creation of rules to generate and control the behaviour of the AutoNaming actions. Before the naming rules can be defined, ensure that appropriate Element rules exist. Click on the ‘Element Rules…’ button to display the ‘Define Rules’ form.


238


This form allows for the definition of the conditions (Element Rules) with which the naming rules must follow. In other words, this form specifies the items which the naming rule(s) will be applicable. The ‘Location’ entries allows for the saving and loading of element rules file from the appropriate rules folders.

Each location entry specifies the possible folder/path to be utilised to save a newly defined rule: ‘User’ indicates that the rules will be stored in the ‘C:\AVEVA\AVEVA Engineering\Data14.1.0\USERDATA’ directory. ‘Project’ indicates that the rules will be stored in the ‘C:\AVEVA\Projects\ACE\acedflts’ project location. ‘Default’ indicates that the rules will be stored in the ‘C:\AVEVA\AVEVA Engineering\Data14.1.0\DFLTS’ directory.

Single AutoNaming rule for all Engineering items (ENGITEs) Select the ‘User’ location, and fill in the details as shown, then click the ‘Include’ button.

The Include button places the name of the element rule in the ‘Defined’ list. It can be observed to be positioned beneath the ‘User Defined Rules’ group, as this is because the ‘User’ rules location was selected. Click the ‘Apply’ and then ‘Cancel’ buttons to return to the ‘Naming Rules’ form. On the ‘Naming Rules’ form, fill in the details as shown


239


The ‘Scan Level’ indicates the scope of the AutoNaming actions. In this case, all applicable items created beneath the World level will be Autonamed. The ‘Rule Name’ entry is selected by clicking on the arrow button next to the entry. This brings up a form listing available conditions/Element rules which this naming rule will apply to.

The ‘Format’ is an expression which will control the pattern of the generated names. The ‘Indices’ is the parameter for including numbering character in the generated name. After filling in the details, click the ‘Insert button to place the created naming rule in the Data Display key list, and also view a summary on the Data section


240


Rules in the Data Display key list can be Cut, Copied, and Replaced using the buttons, as part of rules management activities. Test the defined rules by selecting an engineering item on a list, and clicking the ‘Test’ button, to display a sample of how the generated autoname will appear. Click the ‘OK’ button to return to the ‘Naming settings’ form. On the ‘Naming Settings’ form, select File > Save to save the rules, then check the ‘Auto Naming On/Off’ checkbox, to turn the naming rule on. Click the ‘OK’ button.

Both the element and Naming rules can now be seen to be stored in the location shown:

From the Mechanical, Electrical, and Process categories, display the Mechanical Equipment and Lines list.


241


Create 2 new Mechanical equipment items, and observe their auto generated names.

Create 2 new Electrical equipment items, and observe their auto generated names.

Finally create 2 new Line items, and observe their auto generated names.


242




The created rule being utilised applies to all Engineering items (ENGITEs) and will apply the naming structure to all engineering elements

Any created item with the ENGITE basetype, will be autonamed, using the configured naming rule.

AutoNames based on expressions Create an Element rule with the following details as shown. Enter the rule expression as shown, as this will set the element condition for the naming rule to apply to Line items only.

Select the newly created element rule for the ‘Rule Name’ within the ‘Naming rules’ form as shown:


243


Create a naming rule, ensuring to fill in the details as shown.

Note: The newly created rule must be placed ‘Before’ previously created rules, so as it will be read by the function first.

Create 2 new Line items, and observe their auto generated names.


244


New items of other element types will continue to be autonamed with the previous naming rule setup earlier, as that still applies to ENGITEs without the extra element rule condition for LINEs.

Create a new Element rule for Mechanical equipment only as shown, and have this saved in the Default naming rule location.

Click the Include button to create the rule in the ‘Defined’ group. The new element rule should now be visible beneath the ‘Defined Rules’ rule group.

www.aveva.com


245


Observe the storage location of the element rule.

Proceed to create the Naming rule as shown.


246


Display a mechanical equipment lists, and create a new mechanical equipment item. Observe the auto generated name.

The utilised expression indicates that only items created in any location (with Owner attribute MechanicalTags) will be autonamed in the defined format.

9.3

AutoNaming conditions

Naming rules will be utilised according to the order they are placed in the Data Display key.

If the conditions of the naming rule at the top of the list are met, then that rule will be used. Else, the conditions in the next placed rule will be analysed, and possibly utilised.

9.4

AutoNaming Examples

Element and Naming rule files can be placed in the rules folder and referenced by the Engineering application. Using the rule files generated within the supplied ACE project, the following autonaming rule formats can be observed These formats utilise the element attribute values and concatenate them to form a required autoname www.aveva.com structure. © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

247


Autonaming rule for lines:

This rule applies to items element types (:LINE)


248


Autonaming rule for Mechanical equipment:

This rule applies to items element types (:EQUIPMENT) and whose database owner is an ENGGRP named: ‘Mechanical-Items’.

www.aveva.com


249


Exercise 11 1. Delete the naming and element rules created during the exercise 2. Have the ‘Auto Naming’ turned ‘ON’ 3. Switch to the ‘Infill’ Naming Mode and save rules in the ‘User’ Location 4. Create an element rule which applies to all engineering items 5. Create a naming rule with the format 'ENGITE-' & !Index & 'B' 6. Create 2 items each, of Line items, Mechanical equipment and Electrical equipment 7. Create an element rule which applies to instrument tags only, using the rule expression: ActType EQ ‘:INSTRUMENT’ 8. Create an element rule which applies to valve tags only, using the rule expression: Owner EQ ( ID /Valve-items ) 9. Create naming rules with the above element rules, and observe the AutoNaming on newly created applicable items


250

CHAPTER 10

Exercise 13 1. From the ‘List and Schedules’ group in the ‘Home’ tab, select ‘Mechanical’ from the category drop down, and open the ‘Mechanical Equipment’ list. 2. Display the ‘Data Management’ ribbon, and select the ‘Compare/Update/Link’ button in the ‘AVEVA Integration’ group, to display the ‘Compare/Update’ form. 3. Click on the now visible ‘Compare/Update Actions’ contextual tab to display its ribbon menu. 4. Select the ‘Design Database’ from the ‘Source Selection’ drop down list. 5. On the ‘Map Element Types’ wizard step, select the ‘Equipment’ from the drop down list, and Map the source type ‘EQUIPMENT’ to the Mapped type ‘:EQUIPMENT’. 6. From the ‘Attributes Mapping(s) step of the wizard map Design attributes to Engineering attributes 7. Map the design attributes ‘Name’, ‘Description’, and ‘Number’ with the engineering attributes ‘Name’, ‘:DESCRIPTION’, and ‘:TAGNUMBER’ respectively, for the ‘Electrical equipment’ and ‘Mechanical Equipment’ element types. 8. Refresh the Compare the Design items with the Engineering items, and observe items with attribute changes, matches, and non matches, for Design Equipment (Utilise the ‘Attribute Details’ tab at the bottom of the Compare/Update grid) 9. Accept all required changes and update the databases. Store new Mechanical Equipment items in the ‘ENGGRP Mechanical - Items’, which is located in the ENGWLD Mechanical-Equipment. 10. Link and ‘Update the attributes’ of new items, then ‘Unlink’ a number of already linked items. 11. Observe the Compare/Update grid, the Electrical Equipment list, and also the database explorer for all changes and updates. 12. Run the comparison and updates with a source Electrical data from an AVEVA Electrical, AVEVA Instrumentation and an AVEVA P&ID project if available


251



252

APPENDICES

1

Appendix A

1.1

New Syntax for Distributed Attributes

There are new syntaxes available to work with distributed attributes.

 

The creation /deletion of the distributed attributes member(s) The manipulating of the individual values on the distributed attributes members.

New and Updated Syntax There are also a small number of pseudo attributes available on elements that are associated with distributed attributes. DATT NEW The NEW command creates a new distributed attribute and associates the CE/on element with it. Syntax: DATT NEW [on ] The example creates a new distributed attribute of type :PRESSURE and associates it with CE. Example: DATT NEW :PRESSURE

DATT DELete The DELete command removes distributed attributes from CE/from element Syntax: DATT DELete ALL [] [from < element>] DATT DELete [FIRST | LAST | ] [from ] The example deletes the last distributed attribute member of type :PROCESS from /MyEquipment. Example: DATT DEL LAST :PROCESS FROM /MyEquipment Q ATT The existing Q ATT have been extended to allow for querying distributed attributes. Syntax: Q ATT [AS ANY | ] The command displays all the values of the :PROCESS type associated with CE. Example: Q ATT AS :PROCESS


253


2 2.1

Appendix B Distributed Attribute and Attribute Syntax

Since more than one instance of a distributed element is handled [n] is used to qualify which instance the user is interested in. The syntax is used on both queries and manipulations of attributes, as well as in PML1 expressions. Syntax: :UDANAME\:UDETNAME Example: -- Query the value of the :local\:process distributed attribute on CE Q :LOCAL\:PROCESS :local\process true -- Set the value of distributed attribute :local\:process to false :LOCAL\:PROCESS false -- Query all LNLIST elements where distributed attribute :local\:process equals true Q ALL LNLIST WITH (:LOCAL\PROCESS EQ true) -- Query the value of the second instance of distributed attribute :local\:process Q :LOCAL\:PROCESS[2] :local\process[2] true -- Set the value of the second instance of distributed attribute :local\:process to false :LOCAL\:PROCESS[2] false -- Query all LNLIST elements where second instance of distributed attribute :local\:process equals true Q ALL LNLIST WITH (:LOCAL\PROCESS[2] EQ true)


254


3 3.1

Appendix C Pseudo Attributes Associated with Distributed Attributes

There are a few number of pseudo attributes available to all elements that may have distributed attributes associated with them.

DLIST - Eligible Distributed Attributes Members The attribute returns a list of all eligible distributed attribute types that may be associated with current element. The list does not consider any constraints defined in the schema. Example: Q DLIST DLIST :PROCESS :PRESSURE

XRLSTT - List Distributed Attributes Member Types Associated This attribute returns a list of all distributed attribute types associated with current element. Example: Q XRLSTT XRLSTT :PROCESS :PRESSURE

XRLIST - List Distributed Attributes Member Associated The attribute returns a list of all distributed attribute members (elements) associated with current element. The attribute may take an optional qualifier on typename. Example: Q XRLIST XRLIST 1 :PROCESS 1 of XPIFLD 2 of XPIFLD 1 of /THEPROCWLD 2 :PRESSURE 1 of XPIFLD 2 of XPIFLD 1 of /THEPROCWLD Q XRLIST (TYPENAME :PROCESS ) 1 :PROCESS 1 of XPIFLD 2 of XPIFLD 1 of /THEPROCWLD

XRQCNT - Count of Distributed Attributes Member Associated The attribute returns the number of distributed attribute members (elements) associated with current element. The attribute may take an optional qualifier on typename. Example: © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

www.aveva.com 255


Q XRQCNT XRQCNT 2 Q XRQCNT (TYPENAME :PROCESS ) XRQCNT 1

XRQELE - Return a Single Distributed Attribute Member The attribute returns a selected distributed attributes member of distributed attribute members (elements) associated with current element. The attribute may take an optional qualifier of typename.and relative position. Example: Q XRQELE XRQELE 1 :PROCESS 1 of XPIFLD 2 of XPIFLD 1 of /THEPROCWLD Q XRQELE ( 1 ) XRQELE 1 :PRESSURE 1 of XPIFLD 2 of XPIFLD 1 of /THEPROCWLD

ATTDST - List of Attributes to Show The attribute is available on the distributed attribute member and returns a list of attributes that should be shown by default as attributes. The attribute fulfils the same purpose as ATTLIS for normal attributes. Example: Q ATTDST ATTDST :TEMP :VISCOCITY

DFHOME - The Evaluated Default Home The attribute is available on the any element, in addition to be used for distributed attributes, it may be used in a generic way. When used specifically for distributed attributes evaluation: It takes the typename of a bindable noun/UDET as qualifier. It evaluates the actual home element using current element as when evaluating the test expressions and returns a nulref or a ref to an XPIWLD element. Note: The evaluation finds the associated DSXHOM from the typename qualifier, after that processing is the same as for the generic case. Using it for generic "find a default home" purposes: The DSXHOM reference passed as a qualifier is used to evaluate the expressions defined in the DSXTST/DSXDST of that DSXHOM. It returns a nulref of the ref of the ID value held in the DHTEXT attribute of the resulting DSXDST. The CE is passed to the expression for evaluation. Example: -- distributed attributes, get the location to store distributed attributes of type process for CE. Q DFHOME ( TYPENAME :PROCESS ) DFHOME /THEPROCESSWORLD © Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

www.aveva.com 256


-- Generic example, get the reference that results of evaluation the DSXHOM /MyHomeSelector for/TESTTHIS. Q DFHOME ( /MyHomeSelector ) OF /TESTTHIS DFHOME /STOREITHERE

Datal As a complement to normal Datal processing of distributed attributes, there is a specialized support that generates datals with the distributed attributes syntax. Syntax: OUTPUT INCLUDE Distributed/ATTRIBUTES ... and other options For example: getting everything under the ZONE /MyZone including any distributed attributes would be done by executing the following output command: OUTPUT INCLUDE DistributedA /MyZone Part of the output would resemble the following, with the distributed attributes statements included: NEW EQUI DATT NEW :Process :Local\:Process false END

For further details on Distributed Syntax, please refer to Database Management Reference Manual.


257

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

Recommend Documents