TRAINING GUIDE
www.aveva.com
AVEVA Plant
(12.1)
System Administration
(Advanced)
TM-1301
www.aveva.com
Revision Log
Date Revision Description of Revision Author Reviewed Approved
22/07/2011 0.1 Issued for Review PDMS 12.1.1 BT
09/11/2011 0.2 Reviewed BT KB
10/11/2011 1.0 Issued for Training PDMS 12.1.1 BT KB NG
05/12/2011 2.0 Issued with latest copyright footer CF - CF
29/02/2012 2.1 Issued for Review PDMS 12.1.SP2 KB
01/03/2012 2.2 Reviewed KB SB
06/03/2012 3.0 Approved for Training PDMS 12.1.SP2 KB SB NG
Updates
In general, 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 (TPS) 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.
www.aveva.com
Copyright
Copyright and all other intellectual property rights in this manual and the associated software, and every part of it (including source code, object code, any data contained in it, the manual and any other documentation supplied with it) belongs to, or is validly licensed by, AVEVA Solutions Limited or its subsidiaries.
All rights are reserved to AVEVA Solutions Limited and its subsidiaries. The information contained in this document is commercially sensitive, and shall not be copied, reproduced, stored in a retrieval system, or transmitted without the prior written permission of AVEVA Solutions Limited. Where such permission is granted, it expressly requires that this copyright notice, and the above disclaimer, is prominently displayed at the beginning of every copy that is made.
The manual and associated documentation may not be adapted, reproduced, or copied, in any material or electronic form, without the prior written permission of AVEVA Solutions Limited. The user may not reverse engineer, decompile, copy, or adapt the software. Neither the whole, nor part of the software described in this publication may be incorporated into any third-party software, product, machine, or system without the prior written permission of AVEVA Solutions Limited, save as permitted by law. Any such unauthorised action is strictly prohibited, and may give rise to civil liabilities and criminal prosecution.
The AVEVA software described in this guide is to be installed and operated strictly in accordance with the terms and conditions of the respective software licences, and in accordance with the relevant User Documentation.
Unauthorised or unlicensed use of the software is strictly prohibited.
Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved. AVEVA shall not be liable for any breach or infringement of a third party's intellectual property rights where such breach results from a user's modification of the AVEVA software or associated documentation.
AVEVA Solutions Limited, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom.
Trademark
AVEVA and Tribon are registered trademarks of AVEVA Solutions Limited or its subsidiaries. Unauthorised use of the AVEVA or Tribon trademarks is strictly forbidden.
AVEVA product/software names are trademarks or registered trademarks of AVEVA Solutions Limited or its subsidiaries, registered in the UK, Europe and other countries (worldwide).
The copyright, trademark rights, or other intellectual property rights in any other product or software, its name or logo belongs to its respective owner.
www.aveva.com
1 Introduction ... 9 1.1 Aim... 9 1.2 Objectives ... 9 1.3 Prerequisites ... 9 1.4 Course Structure ... 91.5 Using this guide ... 9
1.6 Setting up the Training Course ... 10
2 Extract Databases ... 11
2.1 Overview ... 11
2.1.1 Creating Extract Databases ... 11
2.1.2 Working in Extract Databases ... 11
2.1.3 Updating Changes from Extract Databases ... 12
2.2 Types of Extract Databases ... 12
2.2.1 Standard Extracts ... 12
2.2.2 Working Extracts ... 12
2.2.3 Variant Extracts ... 13
2.3 Write Access to an Extract Databases... 13
2.4 Extract Families ... 13
2.4.1 Querying Extract Families ... 14
2.5 Choosing an Appropriate Database ... 14
2.6 Extract Data Control in Design ... 15
2.6.1 The Get All Changes Button ... 15
2.6.2 The Update CE Button ... 16
2.6.3 The Extract Claimlists Button ... 16
2.6.4 The User Claimlists button ... 16
2.6.5 The Extract Button... 17
2.6.6 Extract Database Operations - Scope... 17
2.6.7 The Prefix Info Button ... 17
2.6.8 Change Highlighting ... 18
2.6.9 Rules and Connections ... 18
2.6.10 The Flush Button ... 18
2.6.11 The Issue Button ... 19
2.6.12 The Drop Button ... 19
2.7 Creating Standard Extract Databases – A Worked Example) ... 20
2.7.1 Create Teams ... 20
2.7.2 Create Users ... 20
2.7.3 Create a Master Database ... 21
2.7.5 Create Standard Extracts ... 22
2.7.6 Create MDBs ... 23
2.7.7 Testing Standard Extract Databases in Design ... 24
2.7.8 Extract Change Highlighting ... 27
2.7.9 Outstanding in Extract ... 28
2.7.10 Introduced by Get All Changes ... 29
2.7.11 Displaying Items Introduced by Get All Changes ... 30
Exercise 1 – Extract Databases ... 32
2.8 Creating Working Extracts – A Worked Example ... 33
Exercise 2 - Testing Working Extracts in Design ... 34
3 Data Access Control (DAC) ... 35
3.1 Data Access Control – Overview ... 35
3.2 ACRs - Roles and Scopes ... 35
3.2.1 Permissible Operations (Perops) ... 36
3.3 Enabling DAC ... 36
3.4 Creating Scopes, Roles and Permissible Operations – A Worked Example ... 36
3.4.1 Creating a Scope... 36
3.4.2 Creating Roles and Permissible Operations ... 37
3.5 Creating Access Control Rights –A Worked Example ... 38
3.5.1 Create an ACR for ALL ... 39
3.6 Setting User Access – A Worked Example ... 39
www.aveva.com
3.6.2 Using Create/Modify User ... 40
3.7 Testing PDMS Access Control ... 41
3.8 Querying User Access in Design ... 42
3.9 DAC –Negative Implementation ... 43
3.10 Setting DAC for use with MDS ... 44
4 Project Setup Using Excel ... 45
4.1 Export to Excel ... 45
4.2 Admin Excel Spreadsheet ... 46
4.2.1 Admin Excel Spreadsheet – Extract Databases ... 46
4.2.2 Admin Excel Spreadsheet – Working Extract Databases ... 47
4.2.3 Admin Excel Spreadsheet – Scope... 47
4.2.4 Admin Excel Spreadsheet – Roles and Perops ... 48
4.2.5 Admin Excel Spreadsheet – ACR ... 49
4.3 Import from Excel... 49
4.3.1 Selecting an MDB for User Defined Data ... 50
4.4 Admin Database Rollback ... 51
Exercise 3 – Project Setup Excel Export / Import ... 52
5 PML Encryption ... 53
5.1 Overview of PML Encryption ... 53
5.2 PML Encryption Utility Program ... 53
5.2.1 Typical workflow ... 53
5.2.2 Licensing ... 53
5.3 Using the PML Encryption Utility Program ... 54
5.4 Choosing Files ... 55
5.4.1 Single File ... 55
5.4.2 All Files in a Folder ... 55
5.4.3 Files in a pmllib -like Folder Tree ... 55
5.4.4 File/Folder paths... 55
5.5 Encryption Algorithms ... 55
5.5.1 Encryption Type 0: No Encryption ... 55
5.5.2 Encryption Type 1: Trivial Encryption... 56
5.5.3 Encryption Type 2: Basic Encryption ... 56
5.5.4 Encryption Type 3: RC4 Encryption ... 56
5.6 Encrypting PML Files – A Worked Example ... 56
5.6.1 Supplied Files ... 56
5.6.2 Directory Structure ... 57
5.6.3 Testing using a Batch File ... 58
5.6.4 Testing the None Option ... 58
5.6.5 Testing the Trivial Option ... 59
5.6.6 Encrypting Multiple Files ... 59
5.6.7 Testing Encrypted Macros ... 60
5.7 Buffering Encrypted Files ... 62
5.8 Editing Published PML Files ... 63
5.9 Using the $R Command ... 63
5.10 Troubleshooting ... 63
6 Intellectual Property Rights Database Protection ... 65
6.1 IPR Protection Overview ... 65
6.2 Changes to Admin for Database Protection ... 65
6.3 Changing Database Protection – A Worked Example ... 67
6.3.1 Testing Database IPR Protection for the Output Command ... 67
6.3.2 Testing Database IPR Protection for the Copy Command ... 68
6.4 Attribute Protection ... 69
6.5 Checking Attribute Protection – A Worked Example ... 69
6.5.1 Creating an MDB in the MAS Project ... 69
6.5.2 Attributes as a Free User ... 70
6.5.3 Attributes as a Restricted User ... 70
6.5.4 Comparing Results ... 71
7 Enhanced Entry Scripts ... 73
7.1 Creating an Encrypted Entry Script ... 73
7.2 Typical Entry Macro ... 75
www.aveva.com
7.4 Enhanced Entry Scripts (PML Publisher Available) ... 76
7.4.1 Typical User Macro ... 76
7.4.2 Creating the Encrypted Entry Script ... 76
www.aveva.com
1
Introduction
The AVEVA Plant (12.1) System Administration (Advanced) training guide is designed as a continuation to the AVEVA Plant (12.1) System Administration (Basic) training guide. It builds on existing PDMS administration concepts and introduces additional functionality to assist administrators.
1.1
Aim
To provide administrators with the knowledge and skills necessary to administer PDMS projects using advanced features and functionality.
1.2
Objectives
Introduce PDMS concepts specific to Extract Databases, Data Access Control, Encryption of files, and Intellectual Property Rights Database Protection.
Explain the basic concepts of Extract Databases.
Show how to create Standard and Working Extract Databases. Create and edit data in an Extract Database.
Explain how Data Access Control can be used to control PDMS data. Demonstrate how to create simple Data Access Control rules. Be able to encrypt PML forms, functions object and macros.
Explain the basic concepts of Intellectual Property Rights Database Protection. Demonstrate the protection of a catalogue database.
1.3
Prerequisites
It is expected that trainees will have completed the TM-1300 AVEVA Plant (12.1) System Administration (Basic) training course. Trainees who can demonstrate a suitable understanding of PDMS administration may also be permitted to undertake the training.
1.4
Course Structure
Training will consist of oral and visual presentations, demonstrations, worked examples and set exercises. Each workstation will have a training project populated with model objects. This will be used by the trainees to practice their methods and complete the set exercises.
1.5
Using this guide
Certain text styles are used to indicate special situations throughout this document. Menu pull downs and button press actions are indicated by bold dark turquoise text. Information the user has to Key-in will be bold red text.
www.aveva.com
Additional information notes and references to other documentation will be indicated in the styles below.
Additional information
Refer to other documentationSystem prompts will be bold and italic in inverted commas i.e. 'Choose function'.
Example files or inputs will be in the courier new font. If users are required to enter information as part of an example, appropriate fonts and styles previously outlined will be used.
1.6
Setting up the Training Course
Create a new project using the Project Creation Wizard. From the start bar select:
Start > All Programs > AVEVA Plant > Design > PDMS 12.1.SP2 > Project Creation Wizard. Enter the following details for the project. Project Training
Code TRA
Address:
C:\AVEVA\plant\PDMS12.1.SP2\project\Training
Click the Create button.
Login to the Administration module of the new PDMS project using the details provided by the trainer. They will typically be similar to this:
Project - Training
Username - SYSTEM
Password - XXXXXX
Click the Login button.
It is not necessary to specify an MDB to enter Admin. Free Users, like SYSTEM, are NOT shown on the Username pull down.In Admin select Utilities > Training Setup… from the main menu to display the Training Admin form.
Select the Training Setup tab. From the Number of Designers option list select 1, then click the Create Project button.
A Progress Bar is displayed in the lower right hand corner of the screen. Additional feedback is provided in the Command Window.
This process sets the project to a known state, ready for the training course. The process may take several minutes, but when complete the user will be returned to the default Admin screen and the Training Setup form will close.
www.aveva.com
2
Extract Databases
PDMS allows a sub-set of databases to be copied from master databases. These sub-sets are referred to as Extract databases. Extract databases may be as simple as a single database allocated to one user, or they may be more complex, catering for multiple designers over a range of disciplines.
Extract databases allow data from a master database to be shared and modified without effecting the master databases. New data can also be created in the extract databases. Any changes made in the extract databases can be returned to the master databases as and when the administrator requires it.
2.1
Overview
Extract databases provided a useful way of controlling data workflow within a discipline and controlling cross discipline modifications. They are also useful for workflows that require persistent claims or workflow in multiple locations (i.e. Global projects).
2.1.1 Creating Extract Databases
An extract can only be created from an existing multiwrite database (i.e. DESI, PADD, CATA and ISOD). As such, extract databases themselves are multiwrite.
Extracts cannot be created from foreign databases and cannot be created from copy databases.
Many Extracts can be created from one Master database. It is also possible to create an extract of an extract, thereby creating an Extract Family.
Extract Families are considered later in this training guide.2.1.2 Working in Extract Databases
When an extract is created, it will be empty, with pointers back to the owning or master database. When elements are worked on in the extract database,they are claimed in the extract in a similar way to simple Multiwrite databases, so no other user can work on them. Claims are persistent from session to session. When work is saved, the changed data will be saved to the extract, not the master database. Any unchanged data will still be read via pointers back to the master database.
Extract databases can be worked on by a user at the same time as another user is working on the master database or another extract. Any changes made in the master database can be updated in the extract database.
www.aveva.com
2.1.3 Updating Changes from Extract Databases
At some stage in the design process it will be necessary to return information from the extract database to the master database. Two methods are available to facilitate this process:
Flush – copies changes to the master database, but claims on elements still persist. This allows other users to see the changes made but ensures that no changes can be made to the elements. Issue – copies changes to the master database and removes all claims from the elements. Other
users can see the changes made and make further modifications if required.
Alternatively, if the data is no longer required it may be Dropped. If data is dropped, no changes will be transferred to the master database but claims on model elements will remain.
2.2
Types of Extract Databases
Three different types of extract databases can be created. Features pertaining to each type of extract database are noted in the sections that follow.
2.2.1 Standard Extracts
Standard extracts are similar to normal multiwrite databases. They can be owned by any team, given any name, and added to MDBs in the usual way.
The claim mode may be implicit or explicit. If an element is being worked on by any other user in the Extract Family, no other user can work on it.
2.2.2 Working Extracts
Working Extracts are created uniquely for an individual user, i.e. ‘one per user’. Working Extracts only require the use of a single MDB.
www.aveva.com
2.2.3 Variant Extracts
Both Standard and Working extracts can be variant extracts. Variants are a special type of extracts in which elements are not claimed from the owner. They are designed to allow users to try out different designs which then may, or may not, be written back to the master database.
When variants are used, all changes are merged together on issue. Changes are handled at attribute level, so that different users can change different attributes on the same element and then merge their changes. No locking is applied to a variant extract, and any locks applied to other extracts are ignored. This allows many users to modify the same element in a given session, but has the disadvantage that any conflicts will not be found until the changes are issued. If two users modify the same attribute, the last change to be merged takes precedence.
PDMS will ensure that all merges comply with the basic database rules, that is, the data will comply with all DICE checking requirements. It cannot check that the data makes sense in design terms. It is recommended that data consistency and clash checks are always carried out on the resulting merged data.
2.3
Write Access to an Extract Databases
Write access to an extract database is controlled in the same way as any other database. The user must be a member of the Team owning the extract and the user must select an MDB containing the extract. Data Access Control can also be applied to limit operations available to users.
Extracts in the same family can be owned by the same team or by different teams.
At this release, an extract can only be created at the bottom of an extract tree.It is not possible to insert a new extract between existing generations, or create a new master for the extract family.2.4
Extract Families
A Master database may have up to 8000 extract databases. Extracts can be created from another extract, forming a hierarchy of extracts (to a maximum of 10 levels). All the extracts derived from the same master are described as an Extract Family.
The original database is known as the Master database. The Master database is the owner or parent of the first level of extracts. If a more complex hierarchy of extracts is created, the lower level extracts will have parent extracts which are not the master. The extracts immediately below an extract are known as extract members.
www.aveva.com
In this example:PIPES is the Master and the parent of PIPES_X1. PIPES_X1 is a child of PIPES and the parent of PIPES_X10. PIPES_X10 is a child of PIPES_X1.
The members of PIPES are PIPES_X1 and PIPES_X2.
2.4.1 Querying Extract Families
The following attributes can be queried to obtain information about the structure of an extract family: Database attributes
EXTNO Extract Number EXTOWN Extract Owner EXTMAS Extract Master EXTALS Extract Ancestors EXTCLS Extract Children EXTDES Extract Descendants
EXTFAM Extract Family ISEXOP Owner Primary Here ISEXMP Master Primary Here ISEXAP Ancestry Primary Here LVAR Variant
LCTROL Controlled
2.5
Choosing an Appropriate Database
It is often advantageous for administrators to use both master databases and extract databases in a project. Suggested use of extract and master database types is provided below:
Use Extract Databases for:
Controlling data workflow within a discipline.
Controlling cross discipline modifications (e.g. supports). Persistent claims.
Integrated working environment with other offices (Global 2).
Use Master databases for:
Enabling cross discipline review/approval of data. Catalogue, Library and Template data.
Splitting data into smaller units to avoid mass data processing through large collections, clashing and spatial map updates.
Controlling the visibility of data in working areas. Controlling the distribution of sub-contractors data. Separating common data for export across projects. Reducing the consequences of possible data corruption.
www.aveva.com
2.6
Extract Data Control in Design
In the Design module extract data is managed using the Extract Data Control form. If extract databases are present in the selected MDB the form can be displayed by selecting Design > Extract Control… from the main menu.
If no extract databases are present in the MDB an error message is displayed.
The following sections detail the functionality contained within the form.
2.6.1 The Get All Changes Button
The Get All Changes button updates an extract with changes made in the owning database. Get all changes can be to a first-level extract from a master database, or to a low-level extract from a higher-level extract (one level at a time). This is similar to doing a Get Work on a normal database.
The From parent extract only and From all extract ancestors radio buttons determine where the changes are taken from.
www.aveva.com
2.6.2 The Update CE Button
The Update CE button refreshes the claim list for the current element.
The prefix “E” is explained later in this chapter.2.6.3 The Extract Claimlists Button
The Extract Claimlists button shows details of the items Extracted to a database. The items are not necessarily claimed by a user.
The Extract Claim options list enables the data to be displayed for the CE, MDB, or a selected database.
2.6.4 The User Claimlists button
Clicking the User Claimlists button enables elements to be claimed in the same way as selecting Utilities > Claimlists… from the main menu.
www.aveva.com
2.6.5 The Extract Button
Clicking the Extract button transfers the write access of a given primary element to an extract.
A claim can be to a first-level extract from a master database, or to a low-level extract from a higher-level extract.
If the extract database has been set-up in Implicit claim mode then modifying the element will claim it automatically.
2.6.6 Extract Database Operations - Scope
The Element Hierarchy and Single Element radio buttons in the Extract DB Operations – Scope area of the form enable either the hierarchy below the identified element, or only the identified element, to be extracted.
Items can be claimed using Utilities > Claim Lists… from the main menu.2.6.7 The Prefix Info Button
Clicking the Prefix Info button displays the Prefix Information form.
The form contains the explanation of the prefix codes and can be used to remind designers of the claim and update condition of the database items.
In this example, Site /SITE-PIPES-AREA01 has prefix codes E and M, meaning that the Site is Claimed and Modified, whilst the zone ZONE-PIPING-AREA01 is just claimed to the extract.
www.aveva.com
2.6.8 Change Highlighting
It is possible to highlight elements in an extract database that will be Issued, Flushed or Dropped or added to the database (following the Get All Changes command) using the Extract Data Control form.
Items that are outstanding in the extract or that have arisen by getting changes from the master database can be displayed this way.
2.6.9 Rules and Connections
When the Always Issue / Flush Changed Rules / Connections checkbox is selected, any related items will also be Issued or Flushed.
This would typically be used where a claimed pipe is connected to equipment nozzles or another pipe. As such, it would be appropriate to Issue (or Flush) the equipment with the pipe and vice versa.
Selecting Resultant Additional Elements… displays additional elements via the Changed Rules & Connections form.
2.6.10 The Flush Button
Clicking the Flush button copies local changes to the owning database but the elements are not released. Users who have access to the owning database can now see the changes, but they cannot make changes to the elements.
www.aveva.com
2.6.11 The Issue Button
Clicking the Issue button copies local changes to the owning database releases the elements.
Users who have access to the owning database can now see the changes and can make changes to the elements.
Following an Issue the Item will not be claimed.2.6.12 The Drop Button
Clicking the Drop button will abandon local changes, i.e. there will be no change to the owning database and it will return to its state before the changes were made (even if the user has done a Save Work).
www.aveva.com
2.7
Creating Standard Extract Databases – A Worked Example)
This worked example creates a number of users, teams and MDB’s that will be used to create a number of extract databases. The effect of flushing and issuing information will also be demonstrated.
2.7.1 Create Teams
For this example three new Teams will be created. Using the Admin Elements form create the following Teams:
MASTERA EXTEAMB EXTEAMC
2.7.2 Create Users
Three new Users are also required. Create the following Users and Passwords:
USER Password
APPRUSERA A
EXUSERB B
EXUSERC C
Make the Users members of the following teams:
USER Team
APPRUSERA MASTERA
EXUSERB EXTEAMB
www.aveva.com
2.7.3 Create a Master Database
For this example, a new master database will be created. From this master database, extract databases will be created.
When creating the master database, ensure that the Master DB radio button is active.
The database type required is a Design database. Name the database DESI.
In the Create SITE textbox enter MASTER/DESI
to create a top level element in the database. Set the Access Mode to Multiwrite and Implicit Claim.
As Extract databases can only be created from a Multiwrite master database it is important that this setting is made correctly.Leave the other settings as the default displayed.
Click the Apply button and dismiss the form. Check that the new database MASTERA/DESI is displayed in the Database and Extracts list.
www.aveva.com
2.7.5 Create Standard Extracts
T
wo extracts of the database will be created and assigned to separate teams. On the Admin Elements form ensure Databases & Extracts is selected in the Elements option list.
Select the Create… button to display Databases & Extracts form and click the An Extract of a DB radio button.
Click the OK button to display the Create Extract form.
Select <DB> MASTERA/DESI from the Select Database for Extract grid.
Select <TEAM> EXTEAMB from the Owning Team grid.
Enter DESI_X1 in the Name textbox.
Select Implicit Claim from the Access Mode options list.
Click the Apply button to create the extract. Repeat the process to create
EXTEAMC/DESI_X2 based on
MASTERA/DESI.
As the extract databases are Multiwrite they appear in the Select Databases for Extract grid.
Extract databases are indicated in Administration forms with an ‘X’.www.aveva.com
2.7.6 Create MDBs
Copy MDB A-PIPING to create an MDB called MASA with a description of Master Extract MDB. Put the MASTERA/DESI database at the top of the Current Databases list.
Create two further copies of MDB A-PIPING named EXTB, description Extract B, and EXTC, description Extract C, respectively.
Put the database EXTEAMB/DESI_X1 at the top of MDB EXTB and the database EXTEAMC/DESI_X2 at the top of MDB EXTC.
www.aveva.com
2.7.7 Testing Standard Extract Databases in Design
Enter PDMS Design with Username APPRUSERA, Password A and MDB MASA. Make the main display window small in height and put it at the top of the screen.
Display the Command Window. Navigate to the World and check that the correct database is being used by entering Q DBNAME in the Command Window.
The returned name should be MASTERA/DESI.
Enter PDMS with Username EXUSERB, Password B and MDB EXTB.
Make the main display window small in height and put it at the bottom of the screen.
Check the correct database is being used.
The returned name should be EXTEAMB/DESI_X1.
In the APPRUSERA session (top of the screen), navigate to the Site MASTERA/DESI and rename it to SITE-MASTERA.
Create a Zone named EQUIP-ZONE and two equipment elements named EQ1 and EQ2.
www.aveva.com
In the EXUSERB session (bottom of the screen), select Design > Extract Control… from the main menu to display the Extract Data Control form.Click the Get All Changes button.
Click in the Elements grid to refresh the form. The re-named Site, the Zone and the two equipment elements are now displayed in the form and Design Explorer.
Close the Extract Data Control form.
In the EXUSERB session (bottom of the screen), create a new equipment element named EQ3 in the same Zone as EQ1 and EQ2.
The equipment is shown bold, indicating that it is claimed.Savework.
In the APPRUSERA session (top of the screen) select Design > Get Work from the main menu. Note that the new equipment, EQ3, is not displayed in the session. This is because the equipment has not been Flushed or Issued to the master database.
www.aveva.com
In the EXUSERB session (bottom of the screen) display the Extract Data Control form again. Note that the EQ3 equipment is prefixed by M, indicating that it has been Modified.The owning zone also has a prefix M, indicating that it has also been modified.
Click the Flush button.
As a Save Work has not been done before the Flush was initiated the following message is displayed:
Click the Yes button to save the changes.
The Extract Session Comment form is automatically displayed.
Click the YES button to confirm the Flush.
Note that the Claim status of the equipment has changed in Extract Data Control form. When a Flush is performed the items are available in the owning database but remain claimed, i.e. EQ3 is prefixed by E, indicating that it is claimed by an extract in this MDB.
www.aveva.com
In the APPRUSERA session (top of the screen) select Design > Get Work from the main menu. Note that the new equipment, EQ3, is now displayed in the session. This is because the equipment has been Flushed to the Master.Try to modify the name of EQ3 in the APPRUSERA session. As the equipment is still claimed by the extract an error message is displayed.
In order for another designer to modify the equipment EQ3 it must be Issued to release the Claim.
2.7.8 Extract Change Highlighting
It is possible to highlight elements in an extract database that will be Issued, Flushed or Dropped or added to the database (following Get All Changes) using the Extract Data Control form.
In the EXUSERB session (bottom of the screen) navigate to the world element.
In the Command Window type Q DBNAME.
It will return Dbname EXTEAMB/DESI_X1 the name of the extract database.
Select Utilities > Training Setup from the main menu.
On the Foundations Tab select the Add TRA.SITE radio button.
www.aveva.com
The newly created site will be displayed in the 3D view.2.7.9 Outstanding in Extract
Select Design > Extract Control... from the main menu to display the Extract Data Control form.
Check the Outstanding in Extract checkbox.
All Design items will be coloured cyan as none of them have been Flushed, or Issued.
The Colour Button can be used to change the display colour.www.aveva.com
The effect of issuing various elements in combination with changing the scope can be seen in the example below. In this instance the Site TRA.SITE has been Issued with the scope set to Single Element. The Zone EQUIP.ZONE has also been Issued with the scope set to Element Hierarchy.2.7.10 Introduced by Get All Changes
Before the Get All Changes command can be used some new items must be created in the parent/master database.
In the APPRUSERA session (top of the screen), navigate to and display Site TRA.SITE. Only the equipment is available.
www.aveva.com
Make a copy of equipment /Tank1 and move it North 5000mm.Save Work.
2.7.11 Displaying Items Introduced by Get All Changes
Return to the previous Design Session EXUSERB (bottom of the screen).
www.aveva.com
Add the site TRA.SITE to the display.Select the Introduced by Get All Changes checkbox.
www.aveva.com
Exercise 1 – Extract Databases
Enter PDMS with Username EXUSERC, Password C and MDB EXTC. Open the Extract Data Control form and click the Get All Changes button to see items that have been added to the Master database. Use Extract Change Highlighting to observe the differences in the graphical display.
Create items as user EXUSERC. Use change highlighting to ensure the items are Outstanding in the Extract. Flush or Issue them back to the Master.
www.aveva.com
2.8
Creating Working Extracts – A Worked Example
Working extracts are allocated to users. In the following worked example working extracts for three users, USERA, USERB and USERC will be created to database MASTERA/DESI.
Return to the Administration module of PDMS. Create Users USERA, USERB and USERC with Passwords A, B and C.
Select Working Extracts from the Elements options list on the Admin Elements form. Click the Create… button to display the Create Working Extracts form.
Select <DB> MASTERA/DESI from the Database to Create Working Extract From grid and <USER> USERA, <USER> USERB and <USER> USERC from the User List grid.
Enter Extract of MASTERA/DESI in the Description textbox.
Click the Apply button to create the Working Extracts.
A new MDB is not required for the Working Extracts.
PDMS may be entered using the same MDB for all three Users as access is controlled by the Username.
Add the three Users to the Team MASTERA.
www.aveva.com
Exercise 2 - Testing Working Extracts in Design
Enter PDMS Design with Username USERA, Password A and MDB MASA. Enter another session of PDMS with Username USERB, Password B and MDB MASA.
Check the database name in each session by entering Q DBNAME in the Command Window. Create some equipment elements in the USERB session and Save Work.
Use the Extract Data Control form to Flush or Issue the database changes back to the Master database. Check that the information is available to USERA following the Get All Changes command.
www.aveva.com
3
Data Access Control (DAC)
Being a member of the team that owns the database controls write access in PDMS. However, due to project security requirements or company working practises, it may be necessary to further restrict data access. By using Data Access Control (DAC) PDMS Administrators can restrict access to PDMS types, names, or particular areas, of the PDMS model.
3.1
Data Access Control – Overview
Data Access Control in regular PDMS projects is governed by team membership. Users must be a member of the Team owning the database in order to write to it.
Normal PDMS data access control will apply to the Project unless the Data Access Control (DAC) option in the Administration module is switched on. Before implementing DAC, administrators need to be aware of the following considerations:
Once DAC is switched on, General Users will not have write access to any elements unless suitable Access Control Rights have been set up.
Free Users always have full access to all elements. DAC can be applied to Update or Multiwrite databases.
When implementing DAC one of two underlying methods are considered.
Users are completely restricted from doing any operation and subsequent permissions allow certain tasks to be carried out.
Users are free to do any operation and subsequent permissions restrict certain tasks from being carried out.
The later method is sometimes refered to as Negative DAC’s.At the heart of DAC is the creation of Access Control Rights (ACR’s) for each user. ACR’s allow the Administrator to:
Restrict access to named elements, given element types, or particular volumes of the model. Restrict the type of operation a User can carry out on elements.
Restrict which attributes a User can set or change.
Further consideration of ACR’s is provided in the sections that follow.
3.2
ACRs - Roles and Scopes
Users can be given one or more ACR’s. Each ACR is made up of two parts, a Role and a Scope.
A Role defines what operations the designer can carry out on which elements e.g. Create, Modify and Delete all types of PDMS elements.
A Scope defines the part of the Design to which the Role applies e.g. a particular Site in DESIGN or Registry in DRAFT, or a specified volume within the model.
Roles and Scopes are referenced by ACR’s and must therefore be created before the ACR has its RoleRef and ScopeRef attributes set.
www.aveva.com
3.2.1 Permissible Operations (Perops)
A Role is a set of Permissible Operations (Perops), which define the operations that can be performed on a given element type.
3.3
Enabling DAC
DAC can be enabled by selecting Project > Data Access Control from the main menu in the Administration module. A confirmation message is displayed.
Clicking the Yes button turns DAC on project wide. The status of DAC is displayed on the Default Toolbar:
3.4
Creating Scopes, Roles and Permissible Operations – A Worked Example
The following worked example will create a Scope for ALL areas of the work, a Role for ALL, a Role for a Piping Designer and Permissible Operations for the Piping Designer.
3.4.1 Creating a Scope
Scopes define the area of the plant where the PDMS Designer can work. The following scope gives access to all areas of the plant.
Click the Access Control Assistant button on the main menu to display the Access Control Assistant form.
Select the Scopes tab in the upper pane of the form. Right click on Scopes and select New scope from the pop-up menu to display a new scope row.
Double click in the Scope name field to edit the information contained within it. Enter ALLSCOPE in the Scope name textbox. In a similar manner enter All Scope in the Scope description text box.
Enter ALL in the Scope selection text box.
www.aveva.com
The syntax used to define Scopes is similar to the syntax used in PML. Key words, such as ALL, can be used in a DAC context. An example of the type of syntax used to define a Scope would be: ALL WITH NAME OF SITE EQ ‘<FULL PDMS NAME OF SITE>’.3.4.2 Creating Roles and Permissible Operations
A Role defines the type of objects that can be created. Roles can be created in two ways; by adding access or by removing access. The removal of access may occur in situations where a designer is initially given full access rights which are then restricted.
3.4.2.1 Create Role and Perop for ALL Access
Select the Roles tab in the upper pane of the form. Right click on Roles and select New role from the pop-up menu to display the new role row.
Enter ALL-DESIGNER in the Role name textbox. Enter Can create ALL PDMS elements in the Role description text box.
A new Permissible Operation (Perop) for the role is required.
Right click on the ALL-DESIGNER entry of the Role name and select New perop from the pop-up menu to display the new perop row.
Enter ALLELE in the Perop name textbox, followed by ALL in the Element types textbox. Leave the Qualifying Condition as unset.
Open the Operations options list. Each entry, i.e. Create, Modify, Delete, etc, has three settings, Ignore, Disallow and Allow. Clicking each entry will cycle through these choices. Set all of the entries to Allow. Set the Attributes field to ALL and the Error message field to Can Create All.
3.4.2.2 Create Role and Perops for Piping Designer Access
The Role of the Piping Designer will allow the creation of pipes and pipe branches providing that the pipe has not been issued. The Pipe Designer may also connect to, and orientate, nozzles.
www.aveva.com
Enter PIPING-DESIGNER in the Role name textbox and Piping Designer in the Role description textbox. Right click on PIPE-DESIGNER entry of the Role name and select New perop from the pop-up menu to display the new perop row.Enter PIPE-DESIGNER-PIPE in the Perop name textbox followed by PIPE in the Element types textbox. Enter (Purp of Zone eq 'PIPE' and Function neq ‘ISSUED’) in the Qualifying condition textbox. Set all the Operations entries to Allow and enter ALL in the Attributes textbox.
Enter You can only create pipes in a Piping Zone that has not been Issued in the Error message textbox.
Create a new perop row to allow the Pipe Designer the ability to orientate position and connect to nozzles. Enter PIPE-DESIGNER-NOZZ in the Perop name textbox followed by NOZZ in the Element type textbox. Leave the Qualifying condition as unset.
In the Operations options list set Create, Output, Export and Copy to Disallow, Delete to Disallow and Modify, Claim, Issue and Drop to Allow.
Enter ORI CREF and POS in the Attributes textbox and enter You can only position, rotate and connect to Nozzles in the Error message textbox.
Create another Perop for the Pipe Designer that will allow Branches to be created if the Pipe has not been issued.
Enter PIPE-DESIGNER-BRAN in the Perop name textbox followed by BRANCH HIERAR in the Element types textbox.
Enter Function of Pipe neq ‘ISSUED’ in the Qualifying condition textbox. Set all the Operations entries to Allow then enter ALL in the Attributes textbox.
Enter You cannot create a Branch or Branch Components if the Pipe has been Issued in the Error message textbox.
The following Perops are now available.
Follow a similar process to create Roles and Perops for the Design Supervisor and the Equipment Designer. For the Role of the Equipment Designer, allow the creation of the equipment hierarchy only where the Purpose of the Zone is EQUIP.
There is no need to create separate SCOPES for the Supervisor, Piping Designer and Equipment Designer. Use the SCOPE /ALLSCOPE for all three users.3.5
Creating Access Control Rights –A Worked Example
Access Control Rights (ACR’s) are used to link Roles and Scopes. To recap, a Role is what a User can do and a Scope is where the user can do it.
www.aveva.com
This worked example creates ACR’s for ALL items (e.g. a supervisor), for Pipe Designers and Equipment Designers.3.5.1 Create an ACR for ALL
Select the ACR’s tab from upper pane of the Access Control Assistant form. Right click on ACR and select New ACR from the pop-up menu to display a new ACR row.
Enter ALL-DESIGN in the ACR name textbox.
Enter Can create ALL items anywhere in the ACR description textbox.
Select the Scopes tab in the top pane. Select the ACR’s tab in the bottom pane.
Using the left mouse button, drag and drop ALLSCOPE from the top pane onto the Scope entry below the ALL-DESIGN ACR entry in the bottom pane.
Click the Roles tab and drag and drop ALL-DESIGN from the top pane onto the Role entry below the ALL-DESIGN ACR entry in the bottom pane.
Repeat this process to create ACRs for ALL-DESIGN, ALL-EQUIPMENT and ALL-PIPES.
3.6
Setting User Access – A Worked Example
Remember, once DAC has been set on then the default access to PDMS is no access, and ACR’s must be set for each User. In this worked example three users will be created and access rights set for each.
A.SUPERVISOR will be the Supervisor and will be given ALL access. A.PIPER will be a Piping Designer and will be given Pipe Designer access.
A.EQUIP will be the Equipment Designer and will be given Equipment Designer access. Create the following users:
A.SUPERVISOR should be a member of all Teams.
A.PIPER should be a member of PIPEN and PIPES.
A.EQUIP should be a member of EQUIPN and EQUIPS.
ACR can be set in two ways, using drag and drop on the Access Control Assistant or by using the Create User or Modify User on the Admin Elements Form.
www.aveva.com
3.6.1 Using Access Control Assistant
In the top pane select the ACRs tab. In the bottom pane select the Users tab. Drag ALL-PIPES onto A.PIPER.
3.6.2 Using Create/Modify User
Select Users in the Element options list of the Admin Elements form.
Select <USER> A.SUPERVISOR and click the Modify… button to display the Modify User: A.SUPERVISOR form.
A.SUPERVISOR should be a member of all Teams. The bottom part of the form shows the ACRs.
The left pane shows all the ACRs available on the project and the right hand pane shows the User’s ACRs.
For A.SUPERVISOR select ALL-DESIGN in the Project ACRs list and move it to the User’s ACRs list with the right arrow button.
Click the Apply button and then the Dismiss button. Repeat the process for A.EQUIP selecting the correct ACRs.
www.aveva.com
3.7
Testing PDMS Access Control
In the previous sections, a number of users have been created and ACR’s have also been created for each user. To re-cap:
A.SUPERVISOR can create anything anywhere.
A.PIPER can only create pipes in a Zone with a Purp of PIPE and where the pipe has not been ISSUED.
A.EQUIP can only create equipment in a Zone with a Purp of EQUI.
The effect of DAC can be seen by testing the ACR’s in design. Ensure that DAC is turned on for the Project then enter a Design session and test the following scenarios:
A.SUPERVISOR Can create Sites, Zones, etc.
A.PIPER Can create Pipes, Branches and components.
Can only create Pipes in a Zone with a Purp of PIPE.
Can only modify Pipes where the Function of the Pipe is not ISSUED.
A.EQUIP Test that Equipment can only be created in a Zone with a Purp of EQUI.
Enter Design as user A.PIPER and navigate to a Nozzle. Select Modify > Attributes from the main menu.
Note that only Position, Orientation and Cref attributes can be modified. All other attributes are greyed out.
www.aveva.com
Make a Pipe the CE. Select Modify > Attributes… from the main menu.Update the Function attribute to ISSUED.
In the Design Explorer navigate away from, then back to, the modified pipe. Note that all the attributes on the form are now greyed out as the Pipe has been Issued.
3.8
Querying User Access in Design
User access in Design may be queried by selecting Query > Project… from the main menu. The Query Project form will be displayed.
The Users tab displays a list of users. Selecting a User from the list displays details about the user including Team membership.
www.aveva.com
DAC may also be queried in Design by selecting Query > Data Access Control… from the main menu to display the Query Data Access Control form.The User Rights tab shows the Role, including the Perops, and the Scope for the current user. Selecting a Perop from the list displays the Perop Properties form.
3.9
DAC –Negative Implementation
Previous examples of DAC have focused on a method of implementation whereby Designers are generally denied access then granted only specific access to achieve certain tasks.
An alternative implementation is where the designer is first given full access and is then restricted from undertaking certain tasks. This is sometimes refered to as Negative DAC’s.
The advantage of using this method is that PDMS can display more meaningful messages. The disadvantage is that there are more Perops for each Designer.
Earlier in this training guide the Role ALL-DESIGNER was created. This role will now be modified to prevent the designer creating equipment. In Admin modify the Role ALL-DESIGNER using the Access Control Assistant and create a new Perop.
Enter / select the following data:
Perop name NOT-EQUIPMENT
Element types EQUIP HIERARCHY
Qualifying Condition unset
Operations Disallow (for all)
Attributes ALL
www.aveva.com
Enter PDMS as A.SUPERVISOR and check that all items except the Equipment Hierarchy can be created.3.10 Setting DAC for use with MDS
Consider the access that might be required for a pipe support designer. The support designer would need access to branch members to create ATTAs, swap elbows, tees etc. They would also need to create branches for Trunnions, create SNODS and joints on steel, and create structures, but only if the Purp of the Zone is SUPP.
The following DAC could be used with the AVEVA Multi Discipline Support system (MDS). To help within this area a variable ‘!!MDSACCESS’ is set to ‘TRUE’ if MDS is running. The following is a list of the required PEROPs for MDS:
Access to Element Condition
BRAN HEIR VTEXT !!MDSACCESS EQ 'TRUE'
REST HEIR VTEXT !!MDSACCESS EQ 'TRUE'
SNOD HEIR ATTRIB PURP OF ZONE EQ 'STL' AND VTEXT !!MDSACCESS EQ 'TRUE'
www.aveva.com
4
Project Setup Using Excel
Project Setup Excel Import and Export is designed to make the process of setting-up an AVEVA Plant project easier by allowing Administration data to be imported via spreadsheets.
It is important that the Excel Spreadsheets used for both the Import and Export functions are in the correct format. The required format is the same for both functions, therefore the correct format can easily be obtained by exporting data from the Administration module and examining the results.
4.1
Export to Excel
The Export to Excel utility can be accessed by selecting Utilities > Export from the main menu of the Administration module.
The Admin Export form will be displayed. From this form the User can enter a file path for the export file.
Alternatively the icon can be used to navigate to a suitable file location.
On clicking the OK button of the Admin Export form the Export process is started.
An export summary screen is displayed. Task progress is displayed in this form. In the event of an error occurring during the export process, it will be noted in this form.
www.aveva.com
4.2
Admin Excel Spreadsheet
The Admin Excel Spreadsheet has a specific format containing a keyword and the appropriate headings.
The spreadsheet is split down into various tabs.This training course will focus on the Extracts and Data Access Control tabs.
4.2.1 Admin Excel Spreadsheet – Extract Databases
The required format for Extract Databases is shown below. Data in some columns can be altered without restriction (e.g. Description), while other columns reflect a value within an appropriate context (e.g. Claim Mode can only be Implicit or Explicit). Guidance on the values required in each column are provided below.
#Keyword EXTRACT.
Owning Team Name of the Team that owns the Extract Database. Name Extract Name (part after /).
Description Description of Database.
Parent Parent Database.
Claim Mode IMPLICIT or EXPLICIT.
www.aveva.com
The required format for Working Extract Databases is shown below. Data in some columns can be altered without restriction (e.g. Description), while other columns reflect a value within an appropriate context (e.g. Claim Mode can only be Implicit or Explicit). Guidance on the values required in each column are provided below.#Keyword WORKEXTRACT.
Owning User Name of the User associated with the Working Extract Database. Description Description of Database.
Parent Parent Database.
Claim Mode IMPLICIT or EXPLICIT.
Variant Yes or No.
4.2.3 Admin Excel Spreadsheet – Scope
On export, Data Access Control requirements are separated into their component parts, ACR,s, ACR Groups, Scopes, Roles and Perops. The required format for Scopes is shown below. As with the other spreadsheets considered, data in some columns can be altered without restriction (e.g. Description), while other columns reflect a value within an appropriate context (e.g. Selection could utilise the keyword ALL). Guidance on the values required in each column are provided below.
#Keyword SCOPE.
Name Name of Scope.
Description Description of Scope.
www.aveva.com
Roles are specified followed by the associated Permissible Operation (PEROP). Roles require only three fields. Guidance on the values required to define the Role are given below.#Keyword ROLE.
Name Name of the ROLE.
Description Description of ROLE.
Permissable Operations require considerably more fields to account for all Create, Modify and Delete operations and any associated error messages. Guidance on suitable values is provided below.
#Keyword PEROP.
Owner Owning Role.
www.aveva.com
Qualifying condition Qualifying Rule. Often this will utilise a Purpose or Function of a model element.OpCreate GRANT or DENY ability to Create Elements. OpModify GRANT or DENY ability to Modify Elements. OpDelete GRANT or DENY ability to Delete Elements. OpClaim GRANT or DENY ability to Claim Elements. OpIssue GRANT or DENY ability to Issue Elements. OpDrop GRANT or DENY ability to Drop Elements. OpOutput GRANT or DENY ability to Output Elements. OpExport GRANT or DENY ability to Export Elements. OpCopy GRANT or DENY ability to Copy Elements. Attributes Specify attributes that can be changed or ALL. Error message Error Message displayed to the User.
4.2.5 Admin Excel Spreadsheet – ACR
The required format for an ACR is shown below. As with the other spreadsheets considered, data in some columns can be altered without restriction (e.g. Description), while other columns reflect a value within an appropriate context (e.g. Scope will reference a valid Scope in the project). Guidance on the values required in each column are provided below.
#Keyword ACR.
Name Name of ACR.
Description Description of ACR.
Scope Name of the Scope.
Role Name of Role.
4.3
Import from Excel
The Import from Excel utility can be accessed by selecting Utilities > Import from the main menu of the Administration module.
The Admin Import form will be displayed. From this form the User can specify a file path for the file to be imported. Alternatively the icon can be used to navigate to a suitable file location.
Before attempting an Excel Import make sure that the Access Control Assistant is not displayed.www.aveva.com
Once the file has been specified, clicking the OKbutton on the Admin Import form instigates the Import operation.
If the project references a Foreign Project the User will be prompted to give suitable login credentials for an a Free User in the referenced project.
An import summary screen is displayed. Task progress is displayed in this form. In the event of an error occurring during the export process, it will be noted in this form.
If errors are present it is possible to role back the System database until a point before the import operation was instigated.4.3.1 Selecting an MDB for User Defined Data
Once the import operation has finished, the System Administrator is prompted to supply an MDB if one has not previously been set.
If the imported data contains UDA’s or UDET’s then the MDB selected should contain a Lexicon Database. As DAC may contain references to UDA’s or UDET’s it is important that this is checked prior to importing the data. If DAC has not been specified, and neither UDA’s or UDET’s have been used, the System Administrator can select <None>.
www.aveva.com
The Admin Database can be rolled back following an Excel import in the event that errors were encountered.The Rollback utility can be accessed by selecting Utilities > Rollback from the main menu.
The Rollback form is displayed showing the items that will be deleted.
Selecting the Rollback button in the middle of the form instigates the process. Due to the nature of this process, confirmation is immediately sought from the User.
Selecting the Yes button continues the process, while selecting the No button stops the process.
If the Rollback process is continued, the lower portion of the Rollback form will be populated with tasks that have taken place.
The user can verify the results of the Rollback process by refreshing the view of the Admin Explorer.
www.aveva.com
Exercise 3 – Project Setup Excel Export / Import
Use the Export to Excel utility on the Training Project. Open the spreadsheet produced and create some new Teams, Users and Databases.
Import the modified spreadsheet into the Training project, checking for any errors.
Use the database Rollback function to restore the project to the point immediately before the Export utility was used.
www.aveva.com
5
PML Encryption
This chapter describes how to create and use PDMS PML Encryption or Published PML. Various levels of encryption can be applied to any PML functions, forms, objects, and macros.
5.1
Overview of PML Encryption
PML is the AVEVA Programmable Macro Language. The details of the language may be found in the PDMS Software Customisation Guide and the PDMS Software Customisation Reference Manual, supplied with the product.
PML functions, objects, forms and macros may be encrypted using the tools described in this chapter. Once encrypted they may be used within PDMS but cannot easily be read.
Please note that the encryption used is of limited strength, and is not secure against all possible attacks. Details of the encryptions used are described later.
Once a PML file has been encrypted, it is no longer possible to read or edit the file. The Published PML toolkit does not include a tool for un-encrypting files. It is good practise to ensure that a safe copy of the original file is retained, in case further modifications are required later.
5.2
PML Encryption Utility Program
The encryption utility program is a command window program designed to be included in the PML software development process.
5.2.1 Typical workflow
When undertaking PML encryption tasks the following workflow should be adhered to: Ensure that a current backup of the source PML is available.
Copy the source folders to a new location.
Encrypt from the source location to the new location.
Check the encryption is successful and the files work in the expected manner.
Not all files within a PML folder hierarchy are always PML. Images, for example, should not be encrypted, but may need to be supplied with the encrypted versions of the PML.
Automating the encryption procedure via batch files, perl script, or a PML script will make it easier to create the encrypted PML files when the source PML is updated.5.2.2 Licensing
The pmlencrypt.exe utility program requires a PML Publisher licence in the license file (the feature name is VPD-PMLPUBLISHER). If this is not present in the license then the program will not run.
www.aveva.com
The form of the PML Encryption Utility Program can be seen by running pmlencrypt.exe without arguments (or with an invalid set of arguments). An output similar to that below is produced.The command is of the form:
pmlencrypt [-rc4|-basic|-trivial|-none] [-buffer N] [-folder|-pmllib] from_path to_path Where:
-rc4 uses 40-bit RC4 encryption from the Microsoft Base Cryptographic Provider (default).
-basic uses a simple low-security encryption algorithm.
-trivial uses a human-decipherable encryption scheme - for testing only.
-none no encryption, but can be used with -buffer N.
-buffer N causes the file to be retained in memory until a module switch once it has been read N times (the default is never).
-folder is used to encrypt ALL files from the folder from_path to to_path.
-pmllib is used to encrypt ALL .pmlobj .pmlfnc .pmlfrm and .pmlmac files from the folders in a PMLLIB-type folder structure beneath from_path to to_path.
from_path is the file or folder to be encrypted.
