AVEVA NET Portal

Fundamentals Guide

4.7.7
AVEVA Solutions Limited

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

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

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

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

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

Copyright
Copyright and all other intellectual property rights in this manual and the associated software, and every part of it
(including source code, object code, any data contained in it, the manual and any other documentation supplied with it)
belongs to, or is validly licensed by, AVEVA Solutions Limited or its subsidiaries.

All rights are reserved to AVEVA Solutions Limited and its subsidiaries. The information contained in this document is
commercially sensitive, and shall not be copied, reproduced, stored in a retrieval system, or transmitted without the
prior written permission of AVEVA Solutions Limited. Where such permission is 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 2003 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

Trademarks
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.
 AVEVA NET Fundamentals Guide

AVEVA NET Fundamentals Guide

Contents Page

AVEVA NET Portal

............................................................................................................ 1-1
1 Introduction
Assumptions
..................................................................................................................................... 1-1
Guide .....................................................................................................................................
Structure 1-1

2 AVEVA............................................................................................................
NET Architecture 2-1
Key Features
..................................................................................................................................... 2-1
AVEVA
.....................................................................................................................................
NET Core Components 2-1

............................................................................................................
3 Enterprise Content and Configuration Management 3-1
Why Enterprise
.....................................................................................................................................
Content and Configuration Management? 3-1
Content
.....................................................................................................................................
and Configuration Management Systems 3-2
Purpose
.....................................................................................................................................
of Data and the role of Configuration Management 3-3
Primary
.....................................................................................................................................
Elements Managed 3-3
What does
.....................................................................................................................................
the Term 'Item' Imply? 3-4
What is
.....................................................................................................................................
Item Data? 3-4
What is
.....................................................................................................................................
a Configuration? 3-5
Identification of an Entity
................................................................................................................................. 3-5

© Copyright 2003 to current year. i 4.7.7

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide

Item ................................................................................................................................. 3-5

What is
.....................................................................................................................................
Configuration Management? 3-5
Configuration Identification
................................................................................................................................. 3-6
Configuration Control
................................................................................................................................. 3-6
Configuration Status Accounting
................................................................................................................................. 3-6
Configuration
.....................................................................................................................................
Identification 3-7
Identification Process
................................................................................................................................. 3-8
Documents
................................................................................................................................. 3-8
Configuration
.....................................................................................................................................
Control 3-9
Change Management
................................................................................................................................. 3-9
Configuration
.....................................................................................................................................
Status Accounting 3-10
Configuration
.....................................................................................................................................
Audit 3-10
Reasons
.....................................................................................................................................
for Content and Configuration Management System 3-11
Benefits
.....................................................................................................................................
of Content and Configuration Management System 3-11

4 AVEVA............................................................................................................
NET Portal Overview 4-1
Integrated
.....................................................................................................................................
Project Execution (IPE) and Integrated Asset Managemant (IAM) 4-1
What are
.....................................................................................................................................
the Major Capabilities of AVEVA NET Portal? 4-2
Data Integration
................................................................................................................................. 4-3
Application Integration
................................................................................................................................. 4-3
Document Management
................................................................................................................................. 4-4
Data Warehousing
................................................................................................................................. 4-4
An "Engineering Portal"
................................................................................................................................. 4-5
Collaboration Platform
................................................................................................................................. 4-5
Information Cross Referencing
................................................................................................................................. 4-5
Overarching Workflow
................................................................................................................................. 4-5
Application Development Platform
................................................................................................................................. 4-6
What Solutions
.....................................................................................................................................
and Benefits Does AVEVA NET Portal Deliver? 4-7
What.................................................................................................................................
are the Generic Benefits? 4-7
What Can
.....................................................................................................................................
AVEVA NET Portal be Used For? 4-8

© Copyright 2003 to current year. ii 4.7.7

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide

A Decision Support & Collaboration Portal Solution

................................................................................................................................. 4-8
An Engineering "Handover" Warehouse Solution
................................................................................................................................. 4-9
An e-Procurement Exchange Solution
................................................................................................................................. 4-9
A Workflow Integrated Asset Lifecycle Knowledge Management Solution
................................................................................................................................. 4-10
What.....................................................................................................................................
are the Major Architectural Aspects of AVEVA NET Portal? 4-11
Enterprise Information & Workflow Model
................................................................................................................................. 4-12

............................................................................................................ 5-1
5 SVG Specification
SVG Documents
..................................................................................................................................... 5-1
Requirements
.....................................................................................................................................
and Recommendations 5-1
Recommendations and Notes on Styling
................................................................................................................................. 5-2
An Example SVG File
................................................................................................................................. 5-4
Further Restrictions
................................................................................................................................. 5-5

............................................................................................................
6 Associative Object and XML Schema 6-1
AVEVA
.....................................................................................................................................
NET Portal Associations 6-1
AVEVA
.....................................................................................................................................
NET Portal Association Types 6-2
AVEVA
.....................................................................................................................................
NET Portal Classes 6-4
Class .....................................................................................................................................
Library or R.D.L. 6-4
Upper.....................................................................................................................................
Ontology and Other System Classes 6-5
Context
..................................................................................................................................... 6-7
Unclassified
.....................................................................................................................................
Objects and the Class UNKNOWN 6-7
Alias Identifiers
..................................................................................................................................... 6-8
Objects Common to Two or More Projects
................................................................................................................................. 6-8
Multiple
.....................................................................................................................................
Classification 6-9
Permissible
.....................................................................................................................................
Associations 6-9
Attributes
..................................................................................................................................... 6-10
Attributes Applied to an Object
................................................................................................................................. 6-12
Attributes Stored in Datasets
................................................................................................................................. 6-13
Documents
.....................................................................................................................................
and Files 6-14
Revisions
.....................................................................................................................................
and Succession 6-15

© Copyright 2003 to current year. iii 4.7.7

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide

AVEVA
.....................................................................................................................................
NET Portal Datasets 6-16
Menusets
.....................................................................................................................................
and Breakdown Nodes 6-18
Collaboration
.....................................................................................................................................
and Mark-up 6-19
Import
.....................................................................................................................................
Templates and Incremental Update 6-20
AVEVA
.....................................................................................................................................
NET Portal Access Control 6-21
Associations
.....................................................................................................................................
and Templates 6-22
AVEVA
.....................................................................................................................................
NET Portal XML Schema Reference 6-45
Reference
.....................................................................................................................................
Data Library (RDL) 6-49

............................................................................................................
7 Glossary of Terms 7-1
Definitions
..................................................................................................................................... 7-1

© Copyright 2003 to current year. iv 4.7.7

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide

© Copyright 2003 to current year. v 4.7.7

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Introduction

1 Introduction
AVEVA NET provides extensive enterprise content management (ECM) and best-of-breed enterprise
configuration management functionality in a single integrated environment. This unique set of
functionality enables the delivery of a range of intelligent information management solutions that
makes sure the efficient capture, management, storage and distribution of all types of information
about the products, assets and/or processes across

and beyond the enterprise. These solutions result in improved operational effectiveness and customer
service, reduced operational costs and enhanced regulatory compliance and safety.

Built on a modern n-Tier architecture and the Microsoft.NET framework, AVEVA NET provides
several key benefits including interoperability and scalability across an enterprise.

This guide is written for Administrators and Users of the AVEVA NET product suite, and includes
information on enterprise content and configuration management principles. In addition to defining the
design principles behind the AVEVA NET system, a Glossary of Terms explain the terminology and
fundamental 'best practices' rules used in the system.

1.1 Assumptions

The are no assumptions made in this document.

1.2 Guide Structure

The guide is divided into chapters, as follows:

AVEVA NET Architecture Describes AVEVA NET and its functionality.

Enterprise Content and Describes the principles of Enterprise Content Management in
Configuration Management context of AVEVA NET.
Principles
AVEVA NET Portal Overview On overview of AVEVA NET Portal and its capabilities.
SVG Specification Describes the use of the SVG specification in context of AVEVA
NET.
Associative Object and XML Describes AVEVA NET Portal Associative Object and XML
Schema Schema
Glossary of Terms A glossary of terms used in this guide.

© Copyright 2003 to current year.

1-1 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Architecture

2 AVEVA NET Architecture

AVEVA NET Workhub is a uniquely open, extensible and non-disruptive technology for exposing,
evaluating and enhancing information networks and the business processes they support. It allows
both new and existing information sources to be progressively interconnected, and provides a range
of management tools which allow the business activities that create or use this information to be
modelled, and their associated processes planned, executed, monitored and controlled. Through
these capabilities, AVEVA NET Workhub creates and manages a multidimensional network of
interrelated information content that connects together people, processes and systems, and helps to
manage the quality, integrity and availability of information across all phases of the product life cycle.

2.1 Key Features

AVEVA NET Workhub combines the latest Internet standards with a range of unique, objectcentric
information management capabilities, thereby enabling controlled, real-time access to correct and
consistent information, irrespective of geographical location.

By separating product and project data from the applications that create it, AVEVA NET Workhub
provides a neutral data management platform for through life product support. This ultimately protects
the huge intellectual and commercial investment made in designing and constructing large-scale
facilities, by allowing data to be accessed, evolved and shared throughout the asset's entire
operational lifetime and, where required, reassembled, revised and reused in future designs.

2.2 AVEVA NET Core Components

AVEVA NET Dashboard is the default user interface for accessing and interacting with information
controlled and managed by AVEVA NET Workhub. It provides a customisable, browser-based
workspace which allows users and administrators from all the organisations and departments
involved in project execution or plant operations to access and work with the information they need.
Through a range of intuitive user-interface features and functionality, the Dashboard provides facilities
to configure how information is arranged and presented to different users, to control what tools are
used for visualising and creating or editing information, and to manage real-time interaction and
collaboration between multiple parties. In its default configuration, Dashboard encompasses the
basic application components below:

Enterprise Explorer - provides the principal mechanism for organising and navigating product and
project data. A variety of features are provided which allow information sets to be defined, and their
associated structures to be represented as conventional explorer-based hierarchies. Structures
can be created for any class of data held in (or referenced by) AVEVA NET Workhub, and both
public and private 'folders' can be defined.

Content Explorer - acts as a secondary navigation aid by displaying a series of categorised links
to the various sets of information which describe the current object and its associations. When an
object is selected, the Content Explorer presents a hyperlink-style list of data sets or documents
pertaining to the currently selected item, plus any metadata defining the nature and/or status of
the information represented by the link. Selecting an entry in the Links pane opens the
corresponding data set or document in the content viewer, using appropriate viewing technology.

© Copyright 2003 to current year.

2-1 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Architecture

Content Viewer - hosts data entry screens, project documents and specific applications accessed
by the user. Each item is displayed as a separate tabbed page and there is no limit to the number
of items that can be simultaneously accessed.

The Content Viewer incorporates standard data presentation and editing media such as form-, grid
and list-based property views, as well as more specialised viewing components for visualising and
collaborating on schematic and spatial (CAD/CAM) models. In addition, it also supports interaction
with standard Microsoft Office products such as Microsoft Excel, Word and Project. In addition to the
functional components above, AVEVA NET Dashboard provides a number of run-time-based
configuration capabilities that allow administrators and/or individual users to customise their
workspace. For example, the various panes making up the Dashboard support resizing, rearranging
and redocking, whilst explorer folders and grid-style data views can be configured to automatically
display specific data and documents of interest to the user. To facilitate internationalisation of
AVEVA NET Dashboard, all GUI components including menus, dialogues, messages and prompts
can be reconfigured to support the required local language.

© Copyright 2003 to current year.

2-2 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Enterprise Content and Configuration Management

3 Enterprise Content and Configuration

Management
Enterprise Content Management is the technologies, tools, and methods used to capture,
manage, store, preserve, and deliver content across an enterprise. At the most basic level,ECM tools
and strategies allow the management of an organisation's unstructured information, wherever that
information exists. Numerous terms are used, depending on whom the user is talking to, nearly
interchangeably with ECM including integrated document management, digital asset management,
integrated document and content management, and total content management to name a few.
Regardless of the precise terminology, ECM capabilities manage traditional content types (images,
office documents, graphics, drawings, and print streams) as well as the new electronic objects (Web
pages and content, email, video, and rich media assets) throughout the life cycle of that content.
Enterprise Configuration Management is a formal discipline with established methods to maintain
the integrity of items (for example products, assets) throughout their life cycle. Configuration
Management is divided into four functional groups:

Function Question
The configuration of the item/product/assets I work with -what
Configuration Identification do they consist of, how do they interface with other systems
and what data underwrites them?
Configuration Control How do I control changes to my item/product/assets?
What changes have been made to the item(s)? What records
Configuration Status Accounting
are maintained?
Does the item conform to the stated needs and is it reflected
Configuration Verification (Audit)
in the supporting data (documentation)?

3.1 Why Enterprise Content and Configuration Management?

Enterprise Content Management and Enterprise Configuration Management are two separate but yet
complimentary disciplines required by enterprises to streamline their business processes, improve
employee productivity and customer satisfaction, make sure regulatory compliance and enhance
safety.

Enterprise Content Management systems are effective in capturing, managing, storing and delivering
content across an enterprise. However, this content does not exist in isolation - it is created to
support a business process, record a transaction or to describe a product, asset or process. The full
value of content is therefore better understood when it is "in context" to what it relates to thereby
giving it relevance and allowing users to understand its meaning.

Configuration Management involves the identification of the products, assets and processes,
including requirements that drives the business. This includes their structure or "make-up" and all
associated documents and records.

The value of an integrated content and configuration management solution is that it not only provides
the ability to manage content throughout its life cycle but it does so "in context" to the products,
assets, processes and requirements that the content relates to. This results in enhanced access to
information, comprehensive change management and vastly improved integrity of information.

© Copyright 2003 to current year.

3-1 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Enterprise Content and Configuration Management

3.2 Content and Configuration Management Systems

An integrated enterprise content and configuration management software system is essential

for the effective management of enterprise information in today's dynamic business environment. The
main elements of such as system are shown below and comprise requirements management,
document/content management, item management,

change management and records management.

These elements can be used individually to address a specific business problem or collectively to
implement an enterprise configuration management process that makes sure that conformance is
maintained between the requirements that drive an enterprise, all its products/assets and all
documents/content that underwrite these.

The full power of an integrated system is that content can be related to the requirements, processes,
products, assets, projects, organisations, locations, people, etc that define an enterprise
environment enabling the effective communication and management of change throughout the
organisation and greatly enhanced access to and integrity of information. This enables different
users, performing different functions to all access a common set of information, thereby eliminating
multiple silos of information and greatly enhancing productivity.

© Copyright 2003 to current year.

3-2 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Enterprise Content and Configuration Management

3.3 Purpose of Data and the role of Configuration

Management

Information and business theory tell us that data, combined with the analysis of this data, provides
us with information. The judgment of information is synonymous with making decisions.

Data is therefore the basis of Decision Making. Decision-making is fundamental to Management in

an enterprise; decisions made in an enterprise are normally communicated by Management Plans.

Data may be capture, preserved and presented in structured or unstructured form. Structured implies
management of the data in an identified and addressable manner, typically as found with databases.
Unstructured data implies non-addressable content and is typically found in electronic files such as
from word processors or image files. Unstructured data is often referred to as content.

An Enterprise-wide Content and Configuration Management system makes sure that the correct data
(documents, drawings, records, metadata, etc) is available, and easily accessible when required, at
the place required, in the correct format required by the user of the data (man or machine)."

3.4 Primary Elements Managed

The primary elements defined and managed in an enterprise content and configuration management
system are items, data/documents and work. This concept is shown in the figure below.

Item data defines the things that is worked with, what they consist of, and how they are made up.
This data needs to be managed in a computer intelligible format so that computer-to-computer
transfer and human interpretation is possible.

Data referenced and stored under the control of the system includes all relevant data and
documents about the 'items' of the enterprise.

Work elements define the work people need to perform, to create and maintain data/ documents
about the products. Human interaction with product data needs to be carefully controlled, monitored
and tracked.

© Copyright 2003 to current year.

3-3 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Enterprise Content and Configuration Management

3.5 What does the Term 'Item' Imply?

"ITEM" is a generic term that refers to the following entities in the enterprise:

Hardware or software which is either designed, manufactured, installed and supported, and/or

Services which are rendered, and/or

Assets which are procured, installed and maintained to conduct business, and/or

Business processes used in the enterprise and/or

Virtual products such as policies and financial instruments.

An enterprise content and configuration management system can be used to model andmanage data
about any or all of the above items, especially where business efficiency can be improved by doing
so.

In the enterprise, business is conducted with or around items by people performing work for which
they require data about the item. The most logical way to access data about the 'item' is through a
model (or definition) of a product, process or asset in such a system.

3.6 What is Item Data?

Item Data Types - The data underwriting an item varies considerably depending on the type of
business conducted by the enterprise, and can include the following:

Developmental/Analysis Data such as Requirement Specifications, Technical Reports,

Simulations and Trade Studies,

Description/Product Make-up Data such as Specifications, Technical Drawings, Parts Lists,

Bills of Material,

Support Data such as Maintenance Manuals, Procedures, Training Manuals,

Historical Data such as Test Reports, Inspection and Audit Reports, Failure Reports,

Business Data such as Marketing and Sales Reports, Program Management Information.

Item Data Media is generated, maintained and used by many different business processes in the
enterprise. To maximise business efficiency, all business processes need quick access to the
correct data in the required format at the most appropriate place. Item data (or information) can exist
in many different forms (media), such as:

Hard copies of documents,

Scanned images,

Computer application data files on hard or removable disks, tape or other media (e.g.
spreadsheets, word processors, CAD/CAM data and software source files),

Microfilm,

© Copyright 2003 to current year.

3-4 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Enterprise Content and Configuration Management

Stored video,

Audio recordings,

References to models that are used to convey information to the end user.

3.7 What is a Configuration?

A configuration is the planned or existing breakdown of an entity by the number, nature, arrangement
and interfaces of its components, to conform to designated functional and/or physical
characteristics.

3.7.1 Identification of an Entity

The requirements of an entity's end-use determine its functional and/or physical characteristics (i.e.
the entity's configuration). The configuration of the entity makes it what it is, giving it the specific
physical, functional and other measurable characteristics, which make it suitable for use.

3.7.2 Item

In the context of Configuration Management, the above entity is called an Item. The item can be
hardware, software, a process or a function, or a combination of these, configured for an identifiable
end-use.

A configured end-use item can be a singular item like a screw, a valve or a resistor, or a complex
piece of equipment like an aircraft, or a complete plant, or a process like brewing beer or performing
a maintenance operation or even an insurance policy.

In the context of content and configuration management, the configured end-use item is called an
end-item or primary ITEM.

3.8 What is Configuration Management?

Configuration Management is a formal discipline with established methods to maintain the integrity of
items throughout their life cycle.

Configuration Management is divided into four functional groups:

Function Question

The configuration of the product/process I work with - what does

Configuration Identification it consist of, how does it interface with other systems and what
data underwrites them?

© Copyright 2003 to current year.

3-5 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Enterprise Content and Configuration Management

Configuration Control How do I control changes to my item/plant configuration?

Configuration Status Accounting What changes have been made to the item(s)?

Does the item conform to the stated needs and is it reflected

Configuration Verification (Audit)
in the supporting data (documentation)?

These four groups are explained in more detail below:

3.8.1 Configuration Identification

To identify and record the configuration of an item, including all associated data, which supports the
identified configuration. Configuration identification comprises the following:

Selecting configuration items,

Identifying components,

Establishing suitable types of data and documents, which describe the item.

These aspects are necessary to satisfy an identified data and document need to create, use,
support and/or dispose of item. The identification process is supported by:

Issuing prime identifying numbers and other descriptive and control attributes to items and
documents associated with the defined configuration,

Approving and releasing identified configurations, associated data and documents.

3.8.2 Configuration Control

To systematically evaluate, justify, coordinate, approve or disapprove proposed changes to the

identified configuration of an item, and/or to data and documents that support the item, as well as the
orderly and complete implementation of approved changes to affected items, data and/or documents
after the approval and release of such identified configurations, data and/or documents.

3.8.3 Configuration Status Accounting

To record and report the data needed to manage configured items effectively. It includes the
following:

Maintaining records of approved configurations, supportive data, documents and identifying

numbers.

Maintaining the status of proposed or approved changes, deviations and waivers to approved
configurations.

Configuration Verification (Audit)

© Copyright 2003 to current year.

3-6 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Enterprise Content and Configuration Management

To verify the physical and/or functional compliance of a configured item with its associated

and approved descriptive data and documents.

3.9 Configuration Identification

The most important entities used by AVEVA NET are physical items, virtual items (functional),
documents and work orders. Once these entities have been defined and identified, the next step is to
relate them to one another. The following relationships can be defined between these entities:

Relate physical items to physical items in a physical breakdown structure (refer to Product
Breakdown Structures),

Relate relevant documents to applicable physical items and virtual items (refer to the relevant
headings dealing with the relationships between physical items, virtual items and documents),

Build document relationships by relating documents to documents (refer to Child Documents),

Relate virtual items to virtual items in a functional/process breakdown structure (refer to Virtual
Item Children),

Relate physical items and virtual items (refer to Virtual Item/Physical Item Relationships).

Relate work orders to any item or document.

© Copyright 2003 to current year.

3-7 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Enterprise Content and Configuration Management

3.9.1 Identification Process

The following diagram shows the process of identifying items and documents, and identifying the
relationships between items and documents and between items and items.

3.9.2 Documents

Documents are entities, which can underwrite physical items or virtual items, that is documents
related to a physical item, or virtual item should describe aspects related to the item. If a specific
document describes aspects related to more than one physical item or virtual item, the document
should be related to all applicable physical items and virtual items.

Although the diagram does not show it, the user can relate the same document to more than one
physical item and/or virtual item.

A document may consist of any number of child documents; for example, a Technical Guide may
include a circuit diagram and an assembly drawing.

AVEVA NET also enables the user to define child documents for a specific parent document, for
example, references or attachments to a document.

© Copyright 2003 to current year.

3-8 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Enterprise Content and Configuration Management

3.10 Configuration Control

AVEVA NET Workhub enables the user to control the configuration of 'items', using the following
functions:

Registering and implementing change requests (refer to Change Requests),

Calculating the change effect analysis (refer to Change Requests).

Configuration Control involves the systematic evaluation, co-ordination and approval or rejection of:

Proposed changes to the documentation which defines a item or product baseline,

Proposed variations to the configuration item (physical and virtual) and its associated
documentation.

Configuration Control also shows the user who holds a particular document, and who needs to be
updated after a change has been implemented.

3.10.1 Change Management

The following diagram illustrates how Configuration Change Control affects the configuration of both
the design (recipe) to build and the status of items, which are already built, called baselines
(photos).

The configuration change effect analysis process makes sure that all possible effects of a proposed
change are highlighted before any decision is taken. This analysis can be used to help determine the
impact including cost of the proposed change resulting in better decision-making.

It also facilitates the full implementation of all approved changes.

© Copyright 2003 to current year.

3-9 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Enterprise Content and Configuration Management

3.11 Configuration Status Accounting

Configuration Status Accounting consists of the following building blocks:

Item serialisation and build history documentation,

The build state of the item/product through deviations and waivers,

The establishment of baselines,

The modification status of the item.

Status Accounting (diagram above) is the process of recording, storing and reporting a specific event,
which influenced the defined configuration, e.g. modifications, deviations or waivers, etc.

The user can keep complete trace-ability of the product through the as-built baseline, and the
deviations and waivers approved for a specific item serial number.

Refer to AVEVA NET Administration Guide for further information.

3.12 Configuration Audit

Configuration Verification is a manual process where the user verifies that data and documents,
which describe the item, correlate with the actual item, or vice versa.

AVEVA NET provides all the data to conduct a physical and functional configuration audit against a
product, or any part of a product.

If there are discrepancies between an item and the data content of its related documents, the user
will have to determine:

Whether the data or documents are correct and the item varies from the stated needs. If the data
or documents are incorrect, they must be changed.

Whether the item complies with the needs and the data or documents are incorrect. If item does
not conform to the specified needs, the user will have to decide whether to accept, reject or rework
the item. The user can also define a deviation or a waiver for the item.

© Copyright 2003 to current year.

3-10 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Enterprise Content and Configuration Management

3.13 Reasons for Content and Configuration Management

System

Today's enterprise environments are complex to manage and control due to rapid change.

Unstructured content, typically represents over 80% of the information within an organisation, is
growing rapidly and generally is poorly managed.

People need rapid access to information that they can rely on in order to effectively perform their
duties.

Today's processes and products are developed simultaneously by more than one group, or using
concurrent engineering processes in order to reduce time to market.

The need to track changes to items and documents under development, in production, deployed in
the field and being maintained is critical in order to maintain control.

The need by various groups to modify configurations and/or data simultaneously.

The need to promulgate correct item data to various business processes and other management
systems, which require product configuration data.

3.14 Benefits of Content and Configuration Management

System

All forms of content can be managed and controlled throughout its life cycle.

Users can get rapid access to accurate information in context to their roles.

Requirements can be modelled and made more visible.

Provides control of development processes.

Products can be reproduced repetitively.

Assets can be operated and maintained more effectively.

Regulatory compliance can be ensured.

Analysis of configuration and/or data change impact on performance, cost and schedule.

Valid data and documentation is always available as a result of the configuration management
process.

The latest version of the data is always available, in the correct format - it is entered only once,
and can be used as many times as required.

Total visibility of the item in terms of its identified data.

© Copyright 2003 to current year.

3-11 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Portal Overview

4 AVEVA NET Portal Overview

AVEVA NET Portal Technology is a unique set of software components, which supports web-centric
business integration in a way that is flexible and completely independent of the scope of
applications, information and workflows involved. It is used by AVEVA to support both application-
product-independent, portal integration solutions, and for ongoing development of the AVEVA
Integrated Project Execution (IPE) application products.

The unique combination of the web component portal architecture of AVEVA NET Portal, and its
Enterprise Information and Workflow Model (EIWM) greatly increases value and reduces risk by
ensuring that implementations can evolve from simple early implementations in a predictable and
cost-effective way. This approach supports pragmatic implementation of extended enterprise
collaboration and workflow management, and exploitation of lifecycle knowledge management
aspirations.

4.1 Integrated Project Execution (IPE) and Integrated Asset

Managemant (IAM)

A major source of time, cost and delay on projects is associated with the management of change
and error checking. Point solution software replacing manual tasks may have improved the individual
task, but did nothing to allow tasks to be executed in parallel, sharing data, ensuring consistency
and with minimum errors.

To drive down the time, cost and effort involved in project execution it was necessary to integrate the
applications, to share the data, to be data-centric (not e-paper centric). For AVEVA this meant
integrating and passing high-quality, high integrity data between the applications within the AVEVA
suite. For instance the Model Object Manager checks the integrity and consistency between 2D
P&ID and the 3D design, or material take-off data is sent from AVEVA Plant to AVEVA VPRM for
purchase requisition purposes.

But this was not enough.

How would this wealth of integrated engineering data be shared with the rest of the organization?

How could users (potentially from partners or customers) in other parts of the world securely
collaborate on global projects?

How could non-technical users, browse the wealth of data in a logical, intuitive manner, without
necessarily the need for the source application?

How could over-arching information and workflow management principles be applied to the data set
as a whole?

How could the same principles and benefits be applied as a whole if the customer was using an in-
house or 3rd party product instead of one of the integrated AVEVA applications?

How could the wealth of engineering data be turned over to an operator for use as a
commissioning, operations and maintenance support tool, without needing the source
applications?

How could the engineering data be maintained in an 'evergreen' state to make sure safe, timely,

© Copyright 2003 to current year.

4-1 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Portal Overview

cost efficient, rework engineering to take place?

How could the Owner-Operator work with global outsourced engineering partners on long or short-
term support contracts and still make sure the integrity of the engineered asset, including for
regulatory purposes.

To answer these and many other operational questions were the reasons for AVEVA NET Portal's
development.

For an Engineering, Procurement and Construction (EPC) company, integration of the tools and
applications used during the capital execution phases of a project is referred to as - Integrated
Project Execution or IPE. For an Owner-Operator (OO) company integration of the tools and
applications used during the operational phases of a plant asset is referred to as Integrated Asset
Management (IAM).

There are a number of major differences between these approaches. The first, and most obvious
difference is the tools and applications that need to be integrated. For an EPC, it is typically design,
engineering and project control tools. For an OO it is typically ERP, asset care and document
management systems.

Another major difference is the user applications that are required from an integrated data set. For
instance a P&ID may be used by an engineering company to make sure design integrity, a
construction company may use the same document for construction and commissioning
sequencing, an operator may use it for maintenance isolations. These are three examples of different
applications that may be applied to the same data set (or indeed e-paper).

A third difference between IPE and IAM is the end-user focus. An EPC deals primarily with the plant
logic, so a tag number and logic hierarchy will be typical access points. For an operator, asset
numbers and system hierarchies may be more useful. These are by no means the only views and
drill downs required, but serve to illustrate the differing views of the same data set that is required by
EPC and OO.

So, integrated data, and a single point of access to it by any authorized party, in a form most to the
task at hand, securely, from any part of the organization, any part of the globe are the main tenets
for AVEVA NET Portal.

AVEVA NET Portal provides the access hub to and from other systems through AVEVA NET Portal
Gateways which will be described later.

4.2 What are the Major Capabilities of AVEVA NET Portal?

AVEVA NET Portal can be deployed using any or all of the functional components indicated below.
In most cases it is typical for an EPC to use AVEVA NET Portal in a 'document management' type
of environment, moving towards an 'engineering portal' and then on to a 'data warehouse' in an
evolutionary mode as the business demands and skills dictate. Though it is quite possible for an
organisation to start with application integration and data warehousing as key start points. Flexibility,
adaptability, evolution and pragmatism are foundational principles of AVEVA NET Portal program.

© Copyright 2003 to current year.

4-2 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Portal Overview

4.2.1 Data Integration

AVEVA's core software application products: AVEVA Plant, AVEVA VPE and AVEVA VPRM are
already significantly integrated. It was therefore not the intention to immediately replace these
integrations with another methodology. Nor was it AVEVA's intention to engineer a completely
proprietary integration framework, as some of its competitors had done.

A consolidated, validated, single source of data, i.e. a data warehouse, is a laudable goal. However,
many projects, particularly in their early phases do not have the time, energy and capital to do the
necessary data modelling research in order to reap the benefits of a data warehouse later in the
project (e.g. at handover). These projects need to be able to start with larger packets of data, (e.g.
documents) and gradually evolve over the project to finer and finer granules of data (e.g. a data
warehouse) as the needs, and demands of the project dictate.

Consider also, many applications today provide flexible user definable attribution and workflow. While
this may seem advantageous to the user community and provide applications that very closely fit
local working practices and procedures, this very flexibility causes tremendous problems for data
integration on global projects. If the same product has not been implemented the same way in all
offices on all projects, the vendor provided application plug-ins and data exchange tools (to such as a
framework, backbone, bus or warehouse) may not provide the confidence in data integrity as was
first envisaged.

Then consider data ownership and rules of succession. The engineer's brain is a remarkable tool. It
can deal with errors; analyse and make judgements on the validity and correctness of data. So,
consider data, perhaps the same granule of data on two different data sheets. In a database
application such as AVEVA VPE the rules of ownership and succession are part of the applications
core. But in a situation where the two data sheets were not managed by the same application, the
framework consolidating the data would need to first name the data elements the same (to establish
that they are indeed holding values about the same thing), establish the rules by which the data was
checked-out and replaced, who had the rights within what stage the potential conflict. Now consider
these rules across every data element created during a project, and it is not hard to see why many
small projects cannot accept data warehouse technologies early in their lifecycle.

AVEVA needed a new, open, pragmatic, approach to data integration: an approach that allowed the
business to store data in fine or coarse granules appropriate to the task at hand; allowed projects to
evolve from coarse granules to fine granules. But still allowed engineers to work with data from many
sources, challenge, confirm and be confident in its integrity.

4.2.2 Application Integration

A key factor in successful engineering projects is that of managing change. It is a well known fact
that process plant information is very highly inter-related and inter-dependant. What would on the
face of it seem a very small an innocuous change can have significant and serious impact on
projects.

To reduce the risks associated with change, or indeed to eliminate the errors associated with data
re-entry and duplication, it is advantageous for us to move to single data entry. That is, enter once
and use many times. However, being able to identify each and every point where that data has been
used, has up until now been a significant effort all of itself. Added to which, engineering is not as
some would have us believe a 'real time' activity.

© Copyright 2003 to current year.

4-3 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Portal Overview

Engineers work to milestones with data of known quality, and integrity. They need to be made aware,
through such mechanisms as publish and subscribe, but cannot be working with constantly updating
data.

4.2.3 Document Management

Document Management has, over a number of years, become largely accepted. However there are
still substantial variations of capability between 'office' and 'engineering' document management
systems. Many AVEVA customers have anything from implementations of document management
systems, such as Documentum and FileNET, to in-house developed deliverable management
systems (largely tied in with Work Breakdown Systems project management), to Internet hosted
exchange systems, to no systems at all.

The AVEVA NET Portal document management capabilities are harmonious with all of the above.

4.2.4 Data Warehousing

AVEVA NET Portal, as with many other data warehouse products in the engineering IT space, is
developed utilizing the EPISTLE and ISO 15926 data modelling and reference data library concepts.
Objects (plant objects) and associations (relationships) form the fundamental concepts of AVEVA
NET Portal. Data capture from source systems, such as some of the most popular plant design and
engineering tools is provided by AVEVA NET Portal XMpLant. Rigorous data mapping and validation
rules can be applied to data presented to AVEVA NET Portal to make sure high quality, high

© Copyright 2003 to current year.

4-4 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Portal Overview

integrity data is available for sharing with other applications.

4.2.5 An "Engineering Portal"

Engineering applications are traditionally, not only highly specialized requiring specialist skills but
also access to proprietary desktop software. Being able to provide access to the wealth of
engineering data to managers, purchasers, field maintenance engineers etc., whether internal to the
company, or to suppliers, partners and customers around the globe, without them needing to have
the source application on their desktop is a goal for the "engineering portal" The "Engineering Portal"
concept is subtly different to the Data Warehousing concept above. With the latter all data is
consolidated in a single place. That is not to say that it is a single source of data, since it is
duplicated from the source, and therefore rigorous update and revision handling mechanisms need to
be in place. The "Engineering Portal" however, may have some duplicated data (since not all
application data can be shared over the internet efficiently), but not all data is duplicated. As such
this concept is a single source of access to the data, as opposed to a single source of data.

4.2.6 Collaboration Platform

When organizations were large vertically integrated and localized communication between functions
was relatively simple. Where a project team or asset is geographically dispersed across time zones,
companies and source technologies collaboration is not as simple. Parties require a common
interface to locate, comment, share and communicate changes to the 'engineering asset', the source
data (either in a data warehouse, document management system or engineering portal domain).

4.2.7 Information Cross Referencing

As indicated in Application Integration above, process plant engineering (and indeed any other data
associated with the plant) is highly inter-related and inter-dependant. Engineering change impact
analysis, or plant configuration management rely on knowing 'where-used'\ and 'used-on'. Not just
between plant objects, but where those objects appear within document records and visa versa.
There have been many attempts at this kind of indexing and referencing. But these have either been
manual (as such when a new revision of data appears the links break), or have been produced semi
automatically by technology companies that may not have the heritage of engineering to comprehend
the complexities (and as such a partially complete or questionable link calls all of the links into
potential disrepute).

4.2.8 Overarching Workflow

Many applications today have very sophisticated workflow models, organizing and moving data from
user to user in accordance with an establish business procedure. This could be seen as an
opportunity for a project management system to fill a gap, or for a generic workflow modelling tool.
However, when applied to global, internet, multi-partner, multiapplication projects, a more generic tool
to bring the collaboration process together would seem to be a better fit.

© Copyright 2003 to current year.

4-5 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Portal Overview

4.2.9 Application Development Platform

High quality, high integrity, highly accessible, highly configurable, highly available engineering data is
an asset that can be put to many uses. A P&ID for example in the design world could be seen as a
single document. However this single document can and does get put to many uses: construction
sequencing, tag out and lock out installation, hydraulic test points, commissioning, hazard and
safety analysis etc. let alone for ongoing engineering work. Utilizing highly available toolset (.Net) on
top of a high quality data set provides the ability to develop many new applications (that may have
previously been stand alone applications using proprietary databases).

The AVEVA NET Portal solution to meet all of the challenges indicated above is a blend of a number
of technologies and standards.

EPISTLE / ISO 15926, for the basic modelling and object/classification principles.

XML for universal means of storage and transport of data across the internet.

Microsoft .Net for the underlying application framework and collaboration mechanisms.

© Copyright 2003 to current year.

4-6 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Portal Overview

4.3 What Solutions and Benefits Does AVEVA NET Portal

Deliver?

AVEVA NET Portal offers all the benefits and opportunities of successful integration of business
information and applications, with extensible scope and a completely flexible, scalable and
distributable architecture. Many of the benefits are simply those of exploiting good knowledge
management and accessibility, independent of any particular applications, but the key benefit of
AVEVA NET Portal is that such benefits can be achieved in a pragmatic and evolutionary way from
simple beginnings.

4.3.1 What are the Generic Benefits?

Cost and risk reduction through accessibility and consistency of information.

Better asset information management can save a significant percentage of total lifecycle cost of
ownership in both the asset creation and asset operation areas. In some phases users can spend
over 30% of their time simply finding and accessing reliable information, and in other phases as
much of 80% of time is spent handling and managing information one way or another.

Typically, individual operations have justified investment in better information access on only a few
moments saved per engineer per document or minutes per day, even where the information itself
remains potentially inconsistent and poorly integrated. Where additional management and visibility of
information integrity and consistency is also achievable, the savings in decision support effort quickly
mount up.

The risk created by poor information access and / or decision support is often cited also as a major
contributor to the risk of plant unavailability, sub-optimal operation or, in the extreme, loss of plant
integrity. Similarly, poorly auditable information records are seen as a compliance risk, with health &
safety issues and statutory licenses to operate being a key concern for most asset operators.

All these savings created simply by better access, integrity and consistency of information still imply
mainly human decision processes. Achieving these qualities also opens up the potential for further
efficiencies through more automated decision support applications, and better collation of
management "dashboard" overviews.

New business arrangements through distributed availability of good information

As well as these enormous cost saving and risk avoidance factors, there are also significant new
benefits for suppliers, contractors and owner-operators in the capital asset market places.

Issues like business globalisation, M&A activities and ubiquitous communications technologies, lead
to demands and expectations that disparate resources and information can be deployed and
exploited remotely, in flexible and economic ways, with new arrangements between business
partners and centres of excellence. Many such opportunities have taken on fashionable B2B, e-Biz
or e-Collaboration guises in the recent climate, but the business logic is real whatever the flavour of
the buzzwords, and whether or not the underlying core business operations remain essentially
unchanged.

The support for remote distribution also extends opportunities for further managed IT services
outsourcing as well as ASP and remote information management services.

© Copyright 2003 to current year.

4-7 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Portal Overview

New products and services enabled by value-added use of reliable knowledge

Another set of benefits arises from re-use and novel use of information.

These may materialise as Knowledge Management, enabling value-added information to be re-used

from project to project, from asset to asset, even business to business, also capturing the feedback
of experience into best practice.

New or additional services or products are enabled, which make new use of existing information.
Typically equipment suppliers may offer pre-sales selection, design or cataloguing services, or
remote after-sales monitoring, spares and support services, or contractors may offer additional
operations phase engineering support services. In return such suppliers or contractors get the benefit
of real operational feedback and consolidation of knowledge and logistics across multiple assets and
customers.

Some will discover information brokering opportunities, and all parties will achieve Customer
Relationship Management type benefits. Another consequential opportunity in having increased
accessibility of, and confidence in, reliable customer (or supplier) information is support for shared
risk and reward arrangements leading to more optimal business operations. The benefit of better
business integration itself.

4.4 What Can AVEVA NET Portal be Used For?

AVEVA NET Portal can be used for the solutions that follow.

4.4.1 A Decision Support & Collaboration Portal Solution

This provides an information access and decision support solution, with single point access and
visual integration of disparate information, whatever their sources and inherent level of workflow
integration or consistency. Presentation through the intuitive portal interface, configurable to the user
context, provides all the basic benefits of enhanced information access.

Together with mark-up and comment creation, communication and associated workflow functions,
this provides a cost-effective collaboration solution, involving both document and application data
sources, whatever their actual level of integration. With the addition of reporting and visualisation
tools, an effective management information solution is also provided.

This simple portal implementation demands little if any additional effort to workflow-integrate
applications and sources of information yet provides immediate benefits. Being an implementation of
the AVEVA NET Portal Technology it also provides a sound basis to evolve into more sophisticated
business integration solutions, as longer-term aspirations become aligned with ongoing operational
needs and opportunities.

© Copyright 2003 to current year.

4-8 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Portal Overview

4.4.2 An Engineering "Handover" Warehouse Solution

With the disparate information sources either remaining federated, or being consolidated into a
common persistent repository, (depending on contractual lifecycles of the applications involved), this
provides a solution to the problem of organising information at key handover phases in the asset
lifecycle. This provides capability for either transferring such a managed warehouse into ownership of
the owner operator, or transfer of consolidated information into O&M phase applications, or both.

For example, the contractor creating the asset information gets the information access benefits
during the creation phase, and the owner operator gets the benefits of accessibility and consistency
of information immediately the asset is handed over, whether or not the "warehouse" implementation
is adopted in the O&M phase, or whether such information is imported into existing O&M phase
systems.

4.4.3 An e-Procurement Exchange Solution

With essential procurement functionality provided either by AVEVA Engineering IT's PRM
application, or by customers existing choice of procurement systems, the integration of a supplier
gateway feature to the collaboration portal provides for a private exchange e- Procurement solution.
The same gateway approach can extend to integration with other available marketplace or public
exchange, with or without adaptors to alternative third-party procurement applications.

The web-centric component architecture enables evolution of such a solution in either or both of two
directions, once a critical mass of information is thus integrated and managed by AVEVA NET
Portal.

Firstly new functionality provided by either new application development or by third party applications
can add new value to the information asset enhancing the knowledge base and relating the
information to best-practice / business process models and applications.

Secondly, the web-centricity makes sure that exploitation of the knowledge base is not limited by
geographical distribution of business resources, or by new business arrangements with partners or
contractors offering or requesting new services or new risk sharing arrangements.

The above solutions represent only examples enabled by AVEVA NET Portal, but most importantly
each can be considered in terms of evolution from earlier simpler solutions. Each is itself extensible
in scope towards the ideal of full asset lifecycle knowledge management, supported by plug-and-play
workflow integrated business applications, independent of the suppliers of those applications.

It makes it possible to deliver immediately justifiable and low-cost-benefit-risk implementations,

whilst ensuring that a wide range of longer-term strategic aspirations can be met, without committing
to decisions about those later implementations until the appropriate operational needs and
opportunities demand it - just-in-time evolution.

Other applications of AVEVA NET Portal technology include, but are not limited to:

Legacy Application Migration

Supplier/Collaborator Exchange

Longevity of Data Storage

© Copyright 2003 to current year.

4-9 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Portal Overview

Plant Configuration Management

Regulatory Compliance

4.4.4 A Workflow Integrated Asset Lifecycle Knowledge Management Solution

As more and more application information sources are workflow integrated using AVEVA NET Portal
technology rather than simply visually integrated through the portal, the more the solution is actually
managing asset information over more of the lifecycle, even where such information remains
distributed around originating applications.

The web-centric component architecture enables evolution of such a solution in either or both of two
directions, once a critical mass of information is thus integrated and managed by AVEVA NET
Portal.

Firstly new functionality provided by either new application development or by third party applications
can add new value to the information asset enhancing the knowledge base and relating the
information to best-practice / business process models and applications.

Secondly, the web-centricity makes sure that exploitation of the knowledge base is not limited by
geographical distribution of business resources, or by new business\arrangements with partners or
contractors offering or requesting new services or new risk sharing arrangements.

The above solutions represent only examples enabled by AVEVA NET Portal, but most importantly
each can be considered in terms of evolution from earlier simpler solutions. Each is itself extensible
in scope towards the ideal of full asset lifecycle knowledge management, supported by plug-and play
workflow integrated business applications, independent of the suppliers of those applications.

It makes possible to deliver immediately justifiable and low-cost-benefit-risk implementations, whilst

ensuring that a wide range of longer-term strategic aspirations can be met, without committing to
decisions about those later implementations until the appropriate operational needs and opportunities
demand it - just-in-time evolution.

Other applications of AVEVA NET Portal technology include, but are not limited to:

Legacy Application Migration

Supplier/Collaborator Exchange

Longevity of Data Storage

Plant Configuration Management

Regulatory Compliance

© Copyright 2003 to current year.

4-10 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Portal Overview

4.5 What are the Major Architectural Aspects of AVEVA NET

Portal?

As stated, AVEVA NET Portal is quite simply a set of generic software components with a common
architecture and model. The key features which make AVEVA NET Portal special

are as follows:

First, AVEVA NET Portal is web-centric. The architecture is web-enabled at every level and within
each component, the most appropriate standard web-based technology having been selected before
implementation. This includes a common "Portal" framework to deliver access and navigation to any
desktop, but also web-implementations of all middleware management components. There are thus
no significant legacy technology compromises in the integration architecture, which in any way
constrain the scalability or distribution options of the information and applications supported.

Secondly, the Enterprise Information and Workflow Model (EIWM) - the integration model embedded
in the AVEVA NET Portal middle-ware components and interfaces, is completely generic and
standards-based, being defined by the minimum of fundamental concepts and supported by
completely extensible libraries of reference entities and data schema (structures). Furthermore this
generic model covers not only information content storage and communication but also supports
completely generic task, document and business process workflow and metadata capabilities.

Thirdly, AVEVA NET Portal is entirely unique, not just in the Process Industries domain, but
probably in any implementation, in rigorously adopting both the above architectural and modelling
principles simultaneously. As a consequence, the componentisation of software functions enables
complete separation between efficient coding of the core functions and the capture of business
workflow rules and information constraints as extensible reference data. This makes sure that not
only does the scope of lifecycle information have unlimited flexibility and evolutionary extensibility,
but the scope of applications, the uses of the information and the organisational and geographical
distribution of business arrangements, can similarly evolve from early, small scale, lower risk
implementations.

Fourthly, the downside is minimal. Whilst this level of flexibility will always make sure reduced
maintenance, upgrade, migration and ongoing lifetime ownership costs generally, there is usually
risk and a price to pay in the cost and lead-time for configuration and customisation of specific initial
implementations. With AVEVA NET Portal however, this drawback is avoidable. On the one hand,
wherever possible, pre-configured (but nevertheless customisable) application product package
solutions or toolkits are offered. Here the application development itself reaps the benefits of standard
component re-use and availability of cost-effective development toolkits. Typically, on the other hand
where, after business analysis and system design, the customer's business problem is not solved
simply by selection of pre-configured application packages, the componentisation itself enables
evolutionary implementation with early benefits. Furthermore the implementation itself benefits from
the fact that the components are highly standardised and re-usable, and that a wider range of
development and integration tools are available competitively.

As indicated earlier the model and architecture are the features, which give AVEVA NET Portal its
unique distinguishing qualities. In the sense described here they are closely related.

The model, the Enterprise Information and Workflow Model (EIWM), covers workflow or behaviour
metadata, as well as information content. The architecture, as described here, is concerned with the
distinct functions performed on that information, and does not itself determine the physical software
component breakdown and distribution, the latter being driven by additional performance and

© Copyright 2003 to current year.

4-11 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Portal Overview

scalability factors in any given implementation. Appropriate choice of standard web technologies for
those components, makes sure this deployment flexibility.

The information, the business rules, and the core functionality are independent of each other. Only
generic information types, structures and information management rules are "hard-wired" into the
core. Business-specific types, structures and rules are handled separately, and all interfaces
between these components are web-enabled in a standard way using a standardised Enterprise
Information and Workflow Model.

4.5.1 Enterprise Information & Workflow Model

The EIWM is a logical framework or meta-model consisting of:

Reference Model
This uses a generic, industry-standard, associative model of fundamental concepts and relationship
types, supporting ISO-15926 Part 2, also known as the EPISTLE Core Model (ECM).

Reference Data Library

This is an extensible library of recognised, shareable specialisations of the above concepts and
relationships, including a specialisation and inheritance hierarchy, additional subsetting hierarchies
for navigation purposes, and a dictionary of names in identifiable contexts. This supports ISO-15926
Part 4, the EPISTLE Reference Data Library (ERDL), and local business extensions.

Template Library

This is an extensible library of recognised XML Schemas, defining standardised re-usable data
structures. These range from the smallest communication packages, or Molecular Templates, to
highly structured documents or publishable information sets. These schemas include both
information content and metadata content. The information content schemas cover mapping by
reference to the ECM and ERDL specialisations and names, structured according to asset
breakdowns and workflow (publish and subscribe) patterns. The metadata content covers such
aspects as ownership and access rights, versioning and business workflow status, validity and
consistency, validation rule references and parameters, workflow behaviour rule references and
parameters. (This metadata content is also mappable to the ECM and ERDL where appropriate.) The
XML Template implementation model used closely supports the concepts being proposed for
standardisation as ISO-15926 Part 7, as well as de facto standard e-Business schema registrations
and protocols (BizTalk, RDF etc.)

The AVEVA NET Portal Architecture - XML in Motion

The AVEVA NET Portal architecture exploits standard web technologies at all levels and supports
XML description of information at all interfaces to the middle tier. At these interfaces, all "XML in
Motion" is defined in terms of the EIWM above. Internal communications at interfaces between
components within the middle tier are also mappable to the same EIWM, though not necessarily
implemented in this form, depending on performance, scalability and distribution demands of the
implementation.

All the key functional services in the middle-tier are distinct software components in order to support
the web centric distribution requirements and the scope of metadata content of the EIWM.

© Copyright 2003 to current year.

4-12 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
AVEVA NET Portal Overview

© Copyright 2003 to current year.

4-13 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
SVG Specification

5 SVG Specification
The following section describes the guidelines that the user must follow when using the SVG
specification within AVEVA NET.

5.1 SVG Documents

Some basic AVEVA NET Portal requirements are:

SVG must be valid with correct use of namespaces.

SVG must be embeddable inside other SVG documents.

SVG must not contain any built-in behaviour or scripting.

SVG must render at a reasonable speed.

SVG must be structured with interactivity in mind and it should be possible to add behaviour to the
SVG using XSLT and embedded metadata.

5.2 Requirements and Recommendations

SVG must be valid according to the SVG 1.0 specification (http://www.w3.org/TR/SVG).

The SVG namespace must be present on the root element and it should be the default namespace
i.e. xmlns=http://www.w3.org/2000/svg.

If there is any use of xlink then the xlink namespace must be included on the root element i.e.
xmlns:xlink=http://www.w3.org/1999/xlink. It is recommended that this namespace always be
included whether xlink is used or not.

Any content not in the SVG or xlink namespaces must be in a custom namespace.

The width and height attributes must be present on the root <svg> element. The use of percentages
must be avoided. Explicit units may be specified if they are one of mm, cm, in, px. If units are not
specified then the width and height must be in mm; (note that px will be taken as mm).

The viewBox attribute must be present and must not be of a different aspect ratio than the width and
height attributes. This attribute allows the SVG document to be embedded in another. A different
aspect ratio makes the calculations of coordinates in user space very difficult.

If the preserveAspectRatio attribute is present on the root <svg> element then it must have the value
of 'xMidYMid meet', (which is the default).

The use of a single <g> element to scale the entire document should be avoided. The viewBox
attribute should be used to define the user coordinate system for the SVG.

A standard template would therefore be:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

© Copyright 2003 to current year.

5-1 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
SVG Specification

<svg width=”..width” height=”..height” viewBox=”..viewBox”

xmlns=http://www.w3.org/2000/svg xmlns:xlink="http://www.w3.org/
1999/xlink">
<title><!-- title --></title>
<desc>
<!-- description -->
</desc>
<!-- content -->
</svg>

There should be no script or built in behaviour within the SVG document. This includes the use of the
<a> anchor element and declarative animations.

Avoid a large number of decimal points for floating point values.

5.2.1 Recommendations and Notes on Styling

There are several methods available for styling of SVG elements. Presentation attributes and style
attributes on an element, internal or external CSS stylesheets and Entities. Indeed, all of these
methods may be used together.

Presentation attributes have least precedence; CSS stylesheets have a higher precedence followed
by style attributes. The highest precedence is given to styling rules that style an element by id.
Elements may have more than one class name in their class attributes, each delimited by a space.

The order in the list is not important but the closest CSS class rule for a given style attribute takes
precedence. Entity references may be used for presentation and style attributes, (by extending the
DTD), which allows the styles to be kept in one place whilst still using presentation/style attributes
on elements. (Adobe’s SVG viewer renders fastest when style attributes are used).

Dynamic Effects
AVEVA recommends that the user applies styling with style attributes only.

To get dynamic effects during interaction with the SVG the user must use the inheritance for styles.
To some extent, this also requires that the user must structure the SVG with interaction in mind.
Elements that might form part of an interaction should be grouped using a <g> element and styled
using a style attribute on the <g> element. Where necessary, child elements should have overriding
style attributes. Interactive feedback, such as changing the stroke colour on a mouseover event, can
then be both fast and easily scripted.

Note: Changing the stroke colour on a mouseover event will be standard behaviour in AVEVA NET
Portal for all <g> elements that have the vnet:id metadata described below and they must
have an explicit stroke style or attribute. An explicit stroke is required because of the use of
XSLT to dynamically add the behaviour to the SVG as it is served by the Web Server. If an
internal stylesheet is used then the style element must have a type attribute of text/cssand its
contents be enclosed in a CDATA element.

© Copyright 2003 to current year.

5-2 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
SVG Specification

If an internal stylesheet is used then the style element must have a type attribute of text/css and its
contents be enclosed in a CDATA element.

How to Embed Metadata, and Tag Info

To be able to add behaviour to the SVG so that it can be used to drive an external system, it will
be necessary to add metadata, or data that is not part of the SVG namespace.

This should be enclosed in a <metadata> element that is a child of the element in question. (Note
that the <metadata> element is in the SVG namespace). This would normally be the first child of
a <svg> or <g> element and there should only be one child <metadata> element. The markup it
contains should be in a namespace declared on its root <svg> element; it isn’t essential that it is
on its root <svg> element but this means that namespaces are only declared once.

In the AVEVA NET Portal, engineering Ids are in the namespace xmlns:vnet=”http://
www.aveva.com/VNET” and appear in the SVG thus:

<metadata><vnet:id>90GMM10CL002</vnet:id></metadata>

This makes it easy to add behaviour specific to AVEVA NET Portal into the SVG, in the form of
JavaScript and tooltips etc, on the fly using XSLT.

Note that one of the things that will be added to the svg on the fly is a <rect> element the size of
the root <svg> element’s viewBox. This is given a fill colour by the presentation layer but will have
a fill of none when printed, (by using a CSS media rule and an internal stylesheet).

Things that Affect Rendering Speed

Deep nesting levels. Deeply nested <g> elements will affect performance and file size.

Styling on every element will slow down rendering and increase file size dramatically.

Avoid using elaborate filter effects and other facilities that adversely affect rendering speed.

Avoid using the opacity style property.

Avoid using stroke except where necessary – it is computationally expensive.

Things that Affect Rendering Quality

Scaled/zoomed text elements if stroke is used. Use fill and set stroke to none.

Using many <line> or <path> elements to build a single shape will not give an acceptable result
where the lines butt, especially when zoomed/scaled. Use a single <path> element to get the
correct joins, (e.g. mitering), between path components.

Not closing paths properly will not give an acceptable result where the start and end of the path
butt. Use the z closepath command to get the correct join.

© Copyright 2003 to current year.

5-3 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
SVG Specification

5.2.2 An Example SVG File

Note: This example is given purely to illustrate some of the points and requirements made
above:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<svg width="500" height="500" viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/
svg" xmlns:vnet="http://www.aveva.com/VNET" xmlns:xlink="http://www.w3.org/1999/
xlink">
<title>Example ASVG</title>
<desc>An example SVG document for VNET</desc>
<rect width="100" height="100” style="stroke:none;fill:whitesmoke"/>

<g style="stroke:darkblue;">
<metadata>
<vnet:id>one</vnet:id>
</metadata>
<circle cx="20" cy="20" r="5" style="fill:lightblue;stroke-width:1;"/>
</g>
<g style="stroke:none;">
<metadata>
<vnet:id>two</vnet:id>
</metadata>
<circle cx="25" cy="40" r="5" style="fill:darkred;stroke-width:1;"/>
</g>
<g style="stroke:green;">
<circle cx="50" cy="40" r="5" style="fill:silver;stroke-width:1;"/>

</g>
<g>
<metadata>
<vnet:id>four</vnet:id>
</metadata>
<circle cx="50" cy="20" r="5" style="fill:darkgreen;stroke:lightseagreen;
stroke-width:1;"/>
</g>
<g style="stroke:yellow;">
<metadata>
<vnet:id>three</vnet:id>
</metadata>
<circle cx="30" cy="60" r="5" style="fill:none;stroke-width:1;"/>
</g>
<g style="stroke:orange;">
<metadata>
<vnet:id>five</vnet:id>
</metadata>
<circle cx="60" cy="60" r="5" style="fill:none;stroke-width:1;pointer-
events:all"/>
</g>
<g style="stroke:skyblue">
<metadata>
<vnet:id>six</vnet:id>
</metadata>
<ellipse cx="50" cy="80" rx="20" ry="10" style="fill:lemonchiffon;
stroke-width:1"/>
</g>
</svg>

© Copyright 2003 to current year.

5-4 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
SVG Specification

5.2.3 Further Restrictions

<symbol> and <use> elements not supported

It should be possible to define symbols libraries as SVG documents with the symbols or
reusable graphics defined in <defs> elements and to use or instantiate them in another
document. Unfortunately this use of xlink to reference <symbol> elements in external
documents is not implemented in many of the currently available SVG viewers, (including the
ADOBE SVG Viewer v3).

Neither of the <symbol> and <use> elements are supported by the translator AVEVA NET
Portal uses to translate SVG into ZGL. The ZGL file is currently used for markup and
collaboration of the document

© Copyright 2003 to current year.

5-5 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6 Associative Object and XML Schema

The AVEVA NET Portal Object itself contains no information (other than an internal system handle)
and is often visualised as a ‘keyring’ with Identifiers and other information attached to it. For an
Object to exist in the AVEVA NET Portal Database, it must have at least one

Identifier which consists of:

An ID which must be present and must be unique.

An optional longer descriptive Name.

An optional Context or namespace for the ID – refer to Context.

An optional Revision name or number – refer to Revisions and Succession.

A fully registered Object will also have a Class as discussed below.

6.1 AVEVA NET Portal Associations

An Association is link between two Objects that can be followed from one Object to another and
there is no limit to the number of Associations an Object may have. Here is an example of one
Object which refers to another Object:

© Copyright 2003 to current year.

6-1 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

All Associations are bi-directional so that they can be followed in either direction from one Object to
another. Most Associations read differently depending on the direction in which they are followed and
this is shown in the diagrams by an arrow. (For simplicity in later diagrams the text is shown only in
one direction.)

An Association can exist only for as long as the two linked Objects exist and if either of them is
deleted AVEVA NET Portal automatically deletes the Association.

6.2 AVEVA NET Portal Association Types

About twenty built-in Association Types have so far been defined. This list shows the most frequently
encountered associations and how they are typically used:

© Copyright 2003 to current year.

6-2 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-3 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.3 AVEVA NET Portal Classes

Ideally, every object is classified and its Class tells us what kind of object it is. Here is an object
classified as a P&ID document:

Two kinds of association are used for classification:

6.4 Class Library or R.D.L.

An Object may only be classified using a pre-defined Class from the Class Library, also known as
the Reference Data Library or R.D.L. AVEVA NET Portal comes supplied with a Class Library of
classes that have been found useful in practice. However, it is not necessary to use the Standard
Class Library as supplied and the user can add classes or create a whole custom Class Library to
suit the job in hand.

When customising a Class Library there are some restrictions. A number of system classes are
defined as subclasses of the AVEVA NET Portal SYSTEM class and they cannot be deleted. The
upper levels of the class hierarchy are system defined and the functionality of AVEVA NET Portal
depends on this basic framework known as the Upper Ontology. Any new Class must directly or
indirectly be a subclass of one of these built-in classes.

It is not possible to delete a Class that is currently in use as an Essential or Incidental classification
of any Object. All such Objects must be deleted before the Class can be deleted.

© Copyright 2003 to current year.

6-4 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.5 Upper Ontology and Other System Classes

The following classes are pre-defined system classes and cannot be deleted. The classes coloured
green represent the Upper Ontology: all user-defined classes must directly or indirectly sub-classed
from one of these classes.

© Copyright 2003 to current year.

6-5 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-6 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.6 Context

An Object Identifier must be globally unique across an entire database. By default, objects have
identifiers in the Global or null Context. For an object in this default Context the object ID must be
globally unique. When a Context is specified, an ID only needs to be unique within the namespace
represented by that Context. Any ID can serve as the Context for any other Identifier. In this next
example, a PUMP is given an ID in the context of the ID of a PLANT:

If the ID of an object is unique within the database, it can be referred to by its short ID, for example
“P-101”. To make sure that an ID refers to a single object the Context must be supplied as well:
“WCP|P-101”. Context is not limited to just one level but can be chained without limit.

Note: The use of the convention used in AVEVA NET Portal of a vertical bar | to separate the
Context from the ID (however this is not valid in the AVEVA NET Portal XML Schema).
Note : The use of Context in AVEVA NET Portal should now be regarded as mandatory. It is in any
case unavoidable when one database contains information from two or more PLANTS or
PROJECTS to prevent clashes of identifier between the two sets of data. In a AVEVA NET
Portal Import Package it is necessary to declare a Root Object and the ID of this object is
normally used as the Context for all the objects in that Import Package.

6.7 Unclassified Objects and the Class UNKNOWN

A fully registered AVEVA NET Portal Object has at least one Identifier and at least one Class.
Objects may exist without a Class but this usually only occurs as a transitional state during data
import. For example, to store an Association between two objects it may be necessary for the
AVEVA NET Portal System to create an object on-the-fly before the full details about that Object
have been imported. In a fully populated database unclassified objects would normally be regarded
as an error and evidence of some problem with data import.

Unclassified objects are reported as if they are classified as UNKNOWN. The UNKNOWN class may
also be used to search for unclassified objects.

© Copyright 2003 to current year.

6-7 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.8 Alias Identifiers

An AVEVA NET Portal Object may have more than one Identifier:

A common example, as shown here, is when PDMS has been used on a project and it is desirable
to identify an object with the PDMS form of the name as it appears on PDMS ISOs as well as the
name appearing elsewhere in the project.

Identifiers can be added and deleted at any time but an Object must always have at least one. The
last remaining Identifier cannot be deleted without deleting the Object itself.

When an object has more than one Identifier, one of them is designated as the ‘Preferred Identifier’
and is the first Identifier given to the object. This is the identifier normally displayed in the AVEVA
NET Portal Dashboard. However the object may still be referred to and search for using any of its
Identifiers.

The AVEVA NET Portal Admin Tool can be used to select a different Identifier as the Preferred
Identifier.

6.8.1 Objects Common to Two or More Projects

An object that is common to two separate plants should be given two identifiers, each with the
Context of the respective Plant. It does not matter whether the ID is the same or different in each
context provided the combined identifiers consisting of Context + ID are unique within the AVEVA
NET Portal Database.

© Copyright 2003 to current year.

6-8 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.9 Multiple Classification

An AVEVA NET Portal Object may have more than one Class:

In this example, the object has an Incidental Classification of FIRE HAZARD as well as an
‘Essential Classification’ of PUMP. When objects are shown in classified lists in the AVEVA

NET Portal Dashboard such objects will be listed twice – once under each class (whether the
classification was Essential or Incidental).

An object may have any number of classes and classifications may be added at any time.

However, when an object has more than one class, these classes ought to be compatible. For
example, an object might be classified as both a ROTARY PUMP and as the PRIMARY FEED
PUMP. It would not make sense for an object to be classified as both a ROTARY PUMP and a P&ID
DIAGRAM though AVEVA NET Portal currently has no built-in checks to prevent this.

6.10 Permissible Associations

The AVEVA NET Portal System permits Associations to be created only where that Association has
been pre-defined as a Permissible Association between objects of such classes. Any of the classes,
both Essential and Incidental classifications, contribute to the set of Permissible Associations

© Copyright 2003 to current year.

6-9 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

between two objects.

A Permissible Association is defined in the Class Library as an Association between two classes:

In this example, any object of type DOCUMENT CONTENT may have a ‘refers to’ Association to any
Object of type EQUIPMENT. However, this does not automatically permit the Association in the
reverse direction. If this is required (unlikely in this case) a second Permissible Association must be
created.

Permissible Associations between Classes are inherited by their subclasses.

Note: For the AVEVA NET Portal Dashboard to function properly, all documents should be sub-
classed directly or indirectly from DOCUMENT CONTENT even in a customised Class Library. Thus
the refers to Association above would be permitted for all documents types.

6.11 Attributes

AVEVA NET Portal Objects may have Attributes. An Attribute is defined as a class in the Class
Library which determines both the name and the data type of the Attribute wherever it is used – the
same Attribute definition can be used for many classes. Every Attribute is directly or indirectly a
subclass of the CHARACTERISTIC class:

The QUALITATIVE CHARACTERISTIC class allows the user to create attributes classes with a
string, real, integer or date data type:

© Copyright 2003 to current year.

6-10 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

These data types control AVEVA NET Portal Attribute searching when doing an advanced find.
Specifying the data type for a characteristic gives the possibility to do query like: searching for notes
created before a specific date (in this case the data type needs to be Date) or searching for
documents where the revision is higher than 3 (in this case the data type needs to be Integer or
Real).

Attributes can be applied directly to an object or to its corresponding datasets.

In AVEVA NET Portal attributes created using the QUALITATIVE CHARACTERISTIC class are also
known as “Characteristic attributes”.

As well as simple typed attributes, i.e. Characteristics, attributes may have Units. Attributes with
Units are known as Properties and are based on the PHYSICAL PROPERTY class. A property has a
Name/Value pair but also a Unit Of Measure (UOM).

An example of a Characteristic might be:

Attribute Name = Flow Type

Attribute Value = Liquid

A Property might be:

Attribute Name = Design Press. Max

Attribute Value = 40

UOM = barg

There are no Units Of Measure defined by default and so they must be defined before any
PropertyClasses are defined.

© Copyright 2003 to current year.

6-11 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

The user must define a System of UOM and then define a UOM class.

A definition of a PropertyClass can then be created that makes use of a UOM (refer to AVEVA NET
Portal XML Schema Reference).

A Measure may have many units. A Measure of Length may have units of m, cm, mm, km, mile,
furlong, chain, ft etc.

A Measure will have a base Unit and all other units will supply a scale factor to convert that unit into
the base unit. Note that this is only used internally for comparisons during searches. A UOM will
only be returned as it was entered into the system. A UOM will never be converted into another UOM
for any other purpose.

Some Units require a Constant as well as a scale for converting to the base unit; an example is
Degrees Centigrade to Fahrenheit. For this purpose a Constant may also be defined for a UOM. In
this case the constant will be added after the scaling has been applied.

Note: The Base Unit for a Measure is the UOM that has no Scale and no Constant definition.

6.11.1 Attributes Applied to an Object

This is the case for all objects which are classified as a class or a subclass of INFORMATION.
Attributes are added to a class by an Attribute Template. An example of a built-in AVEVA NET
Portal class with an Attribute Template is the DATASHEET class:

When an object of this class or any of its subclasses is created, an Attribute Template Instance is
automatically created and assigned to the object. So for example, here is an object of class
EQUIPMENT DATASHEET which is a subclass of DATA SHEET:

© Copyright 2003 to current year.

6-12 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.11.2 Attributes Stored in Datasets

This is the case for all objects which are NOT classified as a class or a subclass of
INFORMATION, for example “PUMP”.

An object can have multiple datasets. They can be created in multiple ways:

by type: MECHANICAL DATASET, OPERATIONS DATASET, PIPING DATASET...

by source: PDMS DATASET, VPE DATASET...

by class: PUMP DATASET, VESSEL DATASET...

by type and source...

Here are the different steps to follow to be able to store attributes in datasets:

Create datasets class as a subclass of DATASET:

Create Attribute Template for each Dataset created: So all objects which have this type of dataset,
will automatically have this attributes created and assigned to this specific object dataset.

Populate attributes with values; here is an example of an object of class PUMP with 2 datasets:

© Copyright 2003 to current year.

6-13 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.12 Documents and Files

This information model distinguishes the logical Document Content from the physical representation
of that Content – usually a FILE object. As an example, an Isometric might be available in two
formats: as an svg file and as also as a VizStream zgl file. The AVEVA NET Portal dashboard
displays an svg file in preference to the VizStream format but the latter must be used for mark-up.

The Document Content and the physical File are represented in the database by separate Objects
linked by an ‘is fulfilled by’ Association.

In this example SCHEMATIC would be a subclass of DOCUMENT CONTENT.

It is important to notice that Associations such as refers to are between the DOCUMENT CONTENT
object and the PUMP – not between the FILE object and the PUMP.

© Copyright 2003 to current year.

6-14 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.13 Revisions and Succession

An object with the same ID as an object already in the database but with a different Revision name is
created as a Successor to the existing object. This is normally only appropriate for documents
though there is in fact no restriction to prevent this mechanism being used with any class of object.

The AVEVA NET Portal Dashboard by default shows the latest Revision – this being chronologically
the most recent successor created in the database. AVEVA NET Portal does not interpret the
Revision name in anyway: it is a just a string that could be a name or a number.

The user has no control over the sequence of Revisions other than by the order in which they are
introduced into the AVEVA NET Portal Database.

© Copyright 2003 to current year.

6-15 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.14 AVEVA NET Portal Datasets

A Dataset is an object containing attributes as a set of name-value pairs stored as a single XML
string within the AVEVA NET Portal Database. The important feature of a Dataset object is that the
attributes do not have to be pre-defined in the Class Library and they have no data type.

© Copyright 2003 to current year.

6-16 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

A Dataset is usually given an Identifier based on the ID of the object for which it is a dataset. It is
possible to use a non-unique name such as ‘Plant Dataset’ in the Context of the owning object.
However in practice this has been found undesirable for performance reasons as it leads to a very
large number of objects with the same ID in the AVEVA NET Portal Database.

Note: Dataset classes should always be sub-classed from the Class DATASET even in a
customised Class Library.

© Copyright 2003 to current year.

6-17 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.15 Menusets and Breakdown Nodes

Configuration of the AVEVA NET Portal Dashboard tree-view is based on these Associations
between a MENUSET, its BREAKDOWNNODES and a user ID, user ROLE and PROFILE.

© Copyright 2003 to current year.

6-18 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.16 Collaboration and Mark-up

The NOTE and VIZSTREAMCOMMENT objects and their associations shown here are built by the
AVEVA NET Portal Dashboard user interface in the process of creating a AVEVA NET Portal NOTE
with mark-up.

© Copyright 2003 to current year.

6-19 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.17 Import Templates and Incremental Update

In this example the import of this template initially creates PUMP P-101 and P&ID PID200_Sht_1. A
template with the same ID is imported at the next update run and exists briefly as a successor to the
original. This creates PUMP-102 and an extra reference to the P&ID. The Import Server then removes
the earlier instance of the template.

This shows the situation after the update with the deleted objects greyed-out. The P&ID and PUMP
P-102 are still referenced so remain whereas PUMP P-101 is no longer referenced has been deleted.
The presence of is a template referring to associations has maintained the existence of the P&ID
object, its identifier and classification throughout the update.

© Copyright 2003 to current year.

6-20 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.18 AVEVA NET Portal Access Control

An object is removed from the public domain by associating it to a security access group object with
the security access group association type (“is in security access group”/ “is a security access
group for”). The protected object is then only accessible by users who are indirectly associated to
that object through a security access group. Note that several security access groups may be
associated to an object, and a user gains access to the object by being associated to any of these.

© Copyright 2003 to current year.

6-21 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.19 Associations and Templates

The above models illustrate how objects and associations are organised and instanced for specific
purposes or functions. This is not the limit of associations that can be created or used. Indeed the
whole notion of ISO 15926 is to create a fully flexible model that can be used to represent any data
object or association. In most data warehouse implementations however, this is typically at a very
granular level. To improve the ‘human readability’ and the systems ‘repeatability/reuse’ of these
objects the idea of templating these objects and associations together is finding acceptance as a
preferred modelling method.

Templates in AVEVA NET Portal are in two categories, Atomic Templates (AT) and Molecular
Templates (MT). An AT is indivisible semantically and normally forms the smallest usable building
block of objects. A MT is indivisible by business implementation, and represents logical groups of
objects that are typically familiar to an end user.

© Copyright 2003 to current year.

6-22 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

The following pages describe typical AT’s and the context in which they are typically used.

© Copyright 2003 to current year.

6-23 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-24 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-25 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-26 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-27 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-28 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-29 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-30 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-31 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-32 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-33 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-34 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-35 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-36 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-37 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-38 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-39 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-40 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-41 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-42 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-43 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

© Copyright 2003 to current year.

6-44 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

6.20 AVEVA NET Portal XML Schema Reference

Object ID (Unclassified)
<Object>
<ID>PID 113</ID>
</Object>

Object with Essential Classification

<Object>
<ID>PID 113</ID>
<ClassID>P&ID</ClassID>
</Object>

Object ID with Access Control

<Object>
<ID>PID 113</ID>
<ACE>Finance Group</ACE>
</Object>

Descriptive Name
<Object>
<ID>PID 113</ID>
<Name>Fuel System Diagram</Name>
<ClassID>P&ID</ClassID>
</Object>

Context
<Object>
<ID>PID 113</ID>
<Context>
<ID>IPE</ID>
</Context>
<ClassID>P&ID</ClassID>
</Object>

Nested Context
<Object>
<ID>PID 113</ID>
<Context>
<ID>Design Documents</ID>
<Context>
<ID>IPE</ID>
</Context>
</Context>
<ClassID>P&ID</ClassID>
</Object>

© Copyright 2003 to current year.

6-45 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

Revision (of Document)

<Object>
<ID>PID 410</ID>
<ClassID>P&ID</ClassID>
<Revision>B</Revision>
</Object>

Association
<Object>
<ID>PID 410</ID>
<ClassID>P&ID</ClassID>
<Association type="refers to">
<Object>
<ID>150-PD-125</ID>
</Object>
</Association>
<Object>

Alias Identifier
<Object>
<ID>PID 410</ID>
<ClassID>P&ID</ClassID>
<Association type="is identified by">
<Object>
<ID>P&ID 410 Sheet 3</ID>
<Context>
<ID>IPE</ID>
</Context>
<Revision>B</Revision>
<Name>Fuel System Sheet 3<Name>
</Object>
</Association>
</Object>

Document File
<Object>
<ID>PID 113</ID>
<Context>
<ID>IPE</ID>
</Context>
<ClassID>P&ID</ClassID>
<Association type="is fulfilled by">
<Object>
<ID> PID_410_SVG </ID>
<Context>
<ID>IPE</ID>
</Context>
</Object>
</Association>
</Object>

© Copyright 2003 to current year.

6-46 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

Attributes
<Object>
<ID>PID_410_SVG</ID>
<ClassID>FILE</ClassID>
<Context>
<ID>IPE</ID>
</Context>
<Characteristic>
<Name>InfoLocator</Name>
<Value>/vs/IPE/P&IDs/P410_Sht_3.svg</Value>
</Characteristic>
<Characteristic>
<Name>InfoType</Name>
<Value>application/zgl</Value>
</Characteristic>
</Object>

Inline Dataset
<Object>
<ID>P100</ID>
<ClassID>PUMP</ClassID>
<Context>
<ID>IPE</ID>
</Context>
<Association type="has dataset">
<Object>
<ID>P100 Data Set</ID>
<ClassID>VPD DATASET</ClassID>
<Context>
<ID>IPE</ID>
</Context>
<Characteristic>
<Name>Bore</Name>
<Value>200</Value>
</Characteristic>
<Characteristic>
<Name>Material</Name>
<Value>Stainless Steel</Value>
</Characteristic>
</Object>
</Association>
</Object>

Import Template
<?xml version="1.0" encoding="UTF-8" ?>
<vl:VNETList
xmlns:vl="http://www.aveva.com/VNET/List"
xmlns="http://www.aveva.com/VNET/eiwm">
<Template><ID>VPE P&ID</ID>

© Copyright 2003 to current year.

6-47 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

:
<Object>
<ID>PID 113</ID>
</Object>
:
</Template>
</vl:VNETList>

Define Units of Measure

<SystemOfUOMClass>
<ClassID>SI</ClassID>
<ClassName>SI</ClassName>
<Definition>SI</Definition>
<UOMClass>
<ClassID>Metre</ClassID>
<ClassName>Metre</ClassName>
<Definition>Metre</Definition>
<Abbrev>m</Abbrev>
</UOMClass>
<UOMClass>
<ClassID>Centimetre</ClassID>
<ClassName>Centimetre</ClassName>
<Definition>Centimetre</Definition>
<Abbrev>cm</Abbrev>
</UOMClass>
</SystemOfUOMClass>

This example is defining the SI system of units of measure, and is also defining two UOM classes,
one for Metre (m) and another for Centimetre (cm). (The Definition is intended to be a description of
the UOM).

Measure classes are defined as in this snippet

<MeasureClass>
<ClassID>Length Measure</ClassID>
<ClassName>Length Measure</ClassName>
<Definition>Length Measure</Definition>
<UnitOfMeasure>
<UOMClassID>Metre</UOMClassID>
</UnitOfMeasure>

<UnitOfMeasure>
<UOMClassID>Centimetre</UOMClassID>
<Scale>0.01</Scale>
</UnitOfMeasure>
</MeasureClass>
Here a Length Measure is defined with its base UOM as Metre and another UOM of Centimetre. Note
the Scale factor to convert the Centimetre to the base unit Metre.

Finally, the definition of a PropertyClass that makes use of a UOM:

© Copyright 2003 to current year.

6-48 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

<PropertyClass>
<ClassID>LENGTH</ClassID>
<ParentClassID>PHYSICAL PROPERTY</ParentClassID>
<ClassName>Length</ClassName>
<Definition>Length</Definition>
<MeasureClassID>Length Measure</MeasureClassID>
</PropertyClass>
To import an Object that uses this Property
<Object>
<ID>TestObject02</ID>
<Context>
<ID>IPE</ID>
</Context>
<Property>
<Name>LENGTH</Name>
<Value>10</Value>
<Units>cm</Units>
</Property>
</Object>

A Property can be provided with an empty <Units/> element (or <Units></Units>).

If Units are not provided then the Property will not gain the Base Unit but will be set to Null.

If a Characteristic is supplied for an attribute that is actually a Property then it will gain the Base Unit
for the Property.

EIA SearchResults will return an empty <Units/> element for Properties that have null Units to match
the EIWM schema.

6.21 Reference Data Library (RDL)

The following is a listing from the AVEVA NET Portal RDL. This listing has been edited to remove
many leaf nodes, replaced with >>>. Please refer to the AVEVA NET Administration Guide on
details of how to review and modify the RDL.

OBJECT
CHARACTERISTIC
PHYSICAL PROPERTY
SYSTEM OF UOM
UOM
OTHER QUANTITY
QUALITATIVE CHARACTERISTIC
Author
AuthorRole
Body
Category
Creation Date
DataSetBody
Datasize

© Copyright 2003 to current year.

6-49 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

Date
Desc
End Date
EXPANSIONRULE
InfoLocator
InfoType
InfoDMSType
InfoDMSLocator
InfoDMSCheckAccess
InfoDMSAccessLocator
Max Errors
Modified Date
PREFERENCE
SEARCHROOTS
UserRole
Start Date
Status
UNICODECOMMENTTEXT
XSLT
STATE / STATUS / DOMAIN
CLOSED
LOGICAL (& OTHER PHYSICAL) OBJECT
ACTIVITY
EVENT
FACILITY
ROLE
INFORMATION
NOTE
CHANGE REQUIRING NEW ACTION
ERROR REQUIRING CORRECTION
NOTE FOR INFORMATION
PROBLEM REQUIRING INSTRUCTION
QUESTION REQUIRING RESPONSE
DATASET
VPD DATASET
VPE DATASET
DOCUMENT CONTENT
PRIMITIVE ENCODED INFO
TEMPLATE
ATOMIC TEMPLATE
MOLECULAR TEMPLATE
DOCUMENT TEMPLATE
ORGANISATION
PERSON
PROJECT
Contractor
Discipline
MATERIALISED PHYSICAL OBJECT
ARTEFACT
ASSET
FILE
NATURAL OBJECT
MATERIAL

© Copyright 2003 to current year.

6-50 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Associative Object and XML Schema

AVEVA NET Portal SYSTEM

SET
COMMISSIONING SYSTEM
MAINTENANCE WORK PACK
PIPING TEST PACK
HVAC TEST PACK
BREAKDOWNNODE
FOLDER
CONTENT FOLDER
IMPORT FOLDER
PERSONAL FOLDER
PUBLIC FOLDER
IMPORT FILE
IMPORT PACKAGE
MENUSET
PROFILE
SECURITY ACCESS GROUP
VIZSTREAMCOMMENT

© Copyright 2003 to current year.

6-51 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

7 Glossary of Terms
The glossary identifies and defines terminology used in the context of Object Data Management. The
definitions relate to the functionality of AVEVA NET, and do not necessarily correspond with
standard definitions.

The user should also refer to the following online documentation provided by Microsoft:

Microsoft Office Server Master Glossary:

http://msdn.microsoft.com/en-us/library/cc307431.aspx

Microsoft SQL Server 2005 Glossary of Terms:

http://msdn.microsoft.com/en-us/library/ms165911.aspx

7.1 Definitions

Wildcard for DB Search

.NET Framework

Microsoft Infrastructure for C#, VB.NET etc.

Wildcard for a database query in Oracle and Microsoft’s SQL Server and MSDE databases

{}

AVEVA NET Portal delimiters for a Revision name/ number string

AVEVA NET Portal separator between Context and object IDt

n - Tier

Multiple computing layers usually comprising of data layers, application layers and presentation
layers.

See also ARCHITECTURE, CLIENT/SERVER.

Access

A level of access assigned to documents and to users defined in the System. Access is normally
provided with view and print functionality in EDMS and copy distribution for hard copy access.

Access must also imply that actions controlled by permissions can only be performed on documents
where access is granted, either individually or at group level.

© Copyright 2003 to current year.

7-1 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Also known as document security.

ActiveX

A set of technologies that enables software components to interact with one another in a networked
environment, regardless of the language in which they were created. ActiveX is built on the
Component Object Model (COM).

Admin Tool

Application for browsing and editing the AVEVA NET Portal database (for Issued data only).

Advanced Find (in the context of AVEVA NET Portal)

A query mechanism that’s supports searching for objects by Class/ ID/ Association to other objects.

Alias (in the context of Identifier)

Any of the identifiers of a AVEVA NET Portal Object with more than one; secondary rather than the
preferred identifier.

Annotation

To put comments and red lines on documents either electronically or on hard copy.

Used to convey changes that need to be made to the master document.

Also known as MARKUP and REDLINING.

Application Program Interface (API)

See also ARCHITECTURE, 3-TIER.

Architecture

See also CLIENT/SERVER, 3-TIER.

Archive

The removal of historical or inactive System managed document's electronic files and/or hard copies,
and the storage of these files or hard copies offline or in designated archive locations.

Archiving

The removal of redundant or obsolete information objects from an on-line access system to an off-line
storage device for safekeeping.

The act of archiving includes the creation of records which identifies the information object, the
archiving event and its relevant information such as date and archiving authority, as well as the
destination archive media and location. The archive system allows access to archive records and the
retrieval of archived information under specified conditions.

Information objects may include electronic files, database records or physical media such as
microfilm or paper.

Storage devices may include digital, analogue or physical devices such as magnetic tape, magnetic
or optical disk, or filing cabinets for physical media.

© Copyright 2003 to current year.

7-2 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

See also DOCUMENTS.

Archiving Policy The act of pre-defining for a specific class of information the archiving
criteria for invoking an archiving event as well as predefining the archiving requirements. Archiving
requirements are also denoted by the term retention.

Archiving criteria may include specific or combinations of criteria such as the expiration of the
specified on-line availability period for the information object, a change in status of the object, by
specific user command, etc.

Requirements for the archiving event may include the pre-definition of the destined archiving storage
media, archiving device and location, archiving period, disposal instruction, etc.

As-built Baseline

See AS-BUILT CONFIGURATION.

As-built Configuration

The As-Built Configuration reflects the exact make-up of a complete main equipment by a set of
serialized items arranged in accordance with a user-defined serial number structure through all
levels.

Each individual serialized item is underwritten by a Object Baseline which completely covers the
exact configuration of the serialized item, including all its underwriting documents and associated
data.

The underwriting documents and data supporting the As-Built Configuration can include the following:

Technical and other supportive documents,

Configuration changes,

Deviations and waivers,

Modifications, and

Build History.

When a serialized component item is removed from a main equipment item serial number structure
(for replacement by another serialized component item), all associated attributes, references to other
AVEVA NET objects, as well as associated documentation, remain associated with the removed
(replaced) component item. The As-Built configuration of the complete main equipment is inherently
updated.

See also BUILD HISTORY, CONFIGURATION, CONFIGURATION CONTROL COMPONENT, DATA,

DOCUMENT, DEVIATION MAIN EQUIPMENT, OBJECT BASELINE, OBJECT DATA, SERIALIZED
ITEM, SERIAL NUMBER STRUCTURE and WAIVER.

As-designed Baseline

See OBJECT BASELINE.

As-maintained Baseline

See AS-BUILT CONFIGURATION and OBJECT BASELINE.

© Copyright 2003 to current year.

7-3 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Application Service Provider (ASP)

Application access over the web.

Active Server Page (ASP) Page

Code on the AVEVA NET Portal server supporting a webpage.

Asset

This object is made up of a combination of the physical item and serial item combination with its own
set of attributes and relationships.

See ITEM, SERIAL ITEM.

Asset Register Code

Code layered over the AVEVA NET Portal Object Manager that converts AVEVA NET Portal COM
Objects to an XML representation.

Association

A bi-directional link between two Objects, the basis of navigating a AVEVA NET Portal Database.

Association Type

User definable types of link that can created between AVEVA NET Portal objects (see also
Permissible Association).

Atomic Template

The smallest unit of storage in a AVEVA NET Portal database (e.g. an Object or Association).

Attributes

An attribute is a single property of an object, or the property of a relationship between objects. An

object or object relationship is described by the values of its attributes. The attribute serves as the
definition for a value type, whereas a property is an instance of the attribute and its value for the
object.

Attributes serve the purposes of:

Describing the identified object or the relationship. Such descriptive attributes may include the
title for a document, the unit of measure for an item, or identifying the relationship between a
child item and a parent item such as the quantity of a child item being used in the parent item.

Controlling applied business logic and user interaction to the manipulation of metadata about the
identified object. Such controlling attributes may include the status for document as approved, or
the status for a physical item as obsolete.

Depending on the control conditions set for a specific attribute value, applied business logic may
control the way in which the business logic and/or user-interface behave.

In the example above, if the document control attribute has been set to "approved", business
logic may disallow change to the document and force the creation of a new revision for the
document.

© Copyright 2003 to current year.

7-4 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Setting indexing criteria and parameters for the object or object relationships to allow search and
finding of the object or object relationship. Such indexing attributes may include descriptive and
controlling attributes.

See also OBJECT and OBJECT IDENTIFICATION and CHARACTERISTICS.

Attribute (in the context of XML)

A name-value attribute pair within an XML Element

Attribute Template

A user-defined set of Attributes for a AVEVA NET Portal Class and its subclasses (analogous to an
OO Class definition).

AVEVAOPE.dll

Software supporting a COM API to the AVEVA NET Portal Object Manager.

Back-up

The process of copying a set of files to a secure medium to be used for data recovery in case of
system or data loss.

Typical customer environments have formal procedures for daily, weekly, and monthly back-ups.

Baseline

An approved and documented reference point formally designated by the user at a specific, time
during the life cycle of an entity. In AVEVA NET these entities maybe a virtual group, physical item
or tag.

This reference point constitutes the complete and current approved configuration identification of the
specific entity, including its associated underwriting documents, data and interfaces to other entities.
When a baseline is declared in AVEVA NET, a baseline document is created by the system.

Approval of the baseline document constitutes the declared configuration of the entity at a point in
time. Any subsequent changes to the data and documents covered by the baseline will be subject to
configuration control.

The baseline maybe used for controlling future changes, as input to a following phase, or to
consolidate and document the results from the preceding phase.

AVEVA NET distinguishes between four types of baselines:

Generic Baseline

Item Baseline,

Object Baseline

Virtual Group Baseline

AVEVA NET can identify multiple baselines, serving different purposes, for an entity.

See also CHANGE, CONFIGURATION CONTROL, CONFIGURATION IDENTIFICATION, DATA,

© Copyright 2003 to current year.

7-5 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

DOCUMENT, DOCUMENT APPROVAL, ITEM BASELINE, OBJECT BASELINE, OBJECT DATA and
OBJECT LIFE CYCLE.

Baseline Definition

A Definition is a collection of rules to be associated to a Generic Baseline document class. Baseline

rules determine what types of objects, filters and options apply when assessing whether an object
should be included in the baseline. Before a Generic Baseline document class can be used it has to
be associated with a definition. A Generic Baseline Document Class may only have one Definition,
but there is no limit to the number of Generic Baseline document classes a user can create.

Basket

In AVEVA NET Modeller, a collection point that can be used to gain quick access to a list of objects
without having to search for them every time they are needed. Any objects placed into the Basket
remain there until they are removed or the Basket is cleared.

Batch Number

An identifier, which, together with an item prime identifier (part/item number), identifies a quantity of
the same item that has been processed as one group i.e. fabricated).

Batch quantities are always associated with batch numbers, which are allocated to maintain records
against the item number/batch combination. This can include:

Object baseline,

Build history, and

Waivers, deviations and modifications.

Items identified in batches are managed in the same way as serialized items. A batch number is
typically allocated to a quantity of the same item for which:

There is no need to maintain records per individual item,

It is impractical to maintain records per individual item, or

When the item cannot be distinguished as a set of individuals (e.g. a volume of a liquid chemical).

See also AS-BUILT CONFIGURATION, BUILD HISTORY, DEVIATION, MODIFICATION OBJECT

BASELINE, SERIALIZED ITEM and WAIVER.

Book-in

See CHECK IN.

Book-out

See CHECK OUT.

Bootstrap.exe

Utility for initialising a AVEVA NET Portal Database.

BootstrapInstances.xml

© Copyright 2003 to current year.

7-6 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Loaded by the Import process to support Sample data.

BootstrapClasses.xml

Loaded by the Import process to support Sample data.

BreakdownNode

A second tier node in the Tree-view with a customisable definition of how it expands.

Business Process

A process in the enterprise which fulfils a specific requirement associated with the objectives for
conducting business.

Examples of business processes are Marketing and Sales, Design and Development, Materials
Management, Quality Assurance, Finance and Administration, etc.

See also ENTERPRISE and PROCESS.

Callout Code

User-written code written in C# or VB.NET invoked by the Import Server during import processing.

Change

In the context of AVEVA NET, change can be effected on item/object approved configuration, data
and documents, i.e.:

The alteration or modification to an item such that its current defined configuration, and thus
associated functional and physical characteristics, are permanently changed - this action will
result in the identification of a new item or item version

and/or

The changing of item descriptive data, or the contents of a document for the purpose of correction -
this action will result in the creation of a revision change of the document and/or item's baseline.

Formal change and the recording thereof is only implemented on approved items and documents.

See also BASELINE, CONFIGURATION CONTROL, CONFIGURATION ITEM DATA, DOCUMENT,

DOCUMENT APPROVAL, DOCUMENT METADATA, ITEM, ITEM APPROVAL ITEM BASELINE,
ITEM METADATA, METADATA, MODIFICATION, OBJECT BASELINE, OBJECT DATA, REVISION
and VERSION.

Change Control

See CONFIGURATION CONTROL.

Change Effects Analysis

A process performed by AVEVA NET to identify all related objects and data associated with an
object which is a candidate for change.

The change effects analysis report forms the prime input to the user, to identify affected prime
objects and to perform an impact analysis.

© Copyright 2003 to current year.

7-7 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

See also CHANGE, CONFIGURATION CONTROL and OBJECT.

Change Order (CO)

A document that authorizes and instructs a change to item configuration(s) component(s), or data or
document(s), in response to a change request.

COs identify all affected items and may also identify related items affected by the change.
Additionally, metadata about the change is also defined, e.g. change class, requisitioner, approver,
project, etc.

A CO is generally the authorizing document for a change, and identifies the responsible persons or
organizations, change instructions, affected items and documents, and schedules.

When a change is authorized to be implemented on an existing item deployed for operational use,
the Change Order can be described as a Modification Order (MO).

See also CHANGE REQUEST, CONFIGURATION CONTROL, CONFIGURATION ITEM, DATA,

DOCUMENT and MODIFICATION.

Change Proposal (CP)

See CHANGE REQUEST.

Change Request (CR)

A document requesting changes to the configuration of an item, and/or changes to its descriptive
data, or document metadata or the contents of a document.

Customers, vendors, suppliers or any member of the object owning organization such as engineering
or manufacturing may submit CR's.

See also CHANGE, CONFIGURATION CONTROL and ITEM.

Characteristics

A list of additional user-definable data fields which can be associated with all main and secondary
objects in AVEVA NET.

See ATTRIBUTES

Characteristic Class

The definition of a simple string attribute (c.f. Property).

Check-in

The process of placing or returning new or changed documents electronic files under control of the
System. If a new revision of a document is being created, this procedure usually initiates a review/
approval process.

Also known as BOOK-IN.

See also CONFIGURATION CONTROL, DOCUMENT and REVISION.

Check-out

© Copyright 2003 to current year.

7-8 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

The process of recording, under system control, that a document's electronic source file(s) is under
revision and that the source document, regardless of its media, is not available, but may be viewable
with adequate warnings.

Also known as BOOK-OUT.

See also CONFIGURATION CONTROL and DOCUMENT.

Circulation

The action of routing one document from person to person for a defined reason.

See also DISTRIBUTION, DISTRIBUTION LISTS

Class

A type that defines interfaces of a particular type of object. A class defines the properties of the
object and the methods used to control the object's behaviour.

Class Library

Also known as the RDL or Reference Data Library containing user-configurable Classes.

Classification

The action of assignment of a hierarchical set of attributes to any object to allocate secondary
identifying data which can be applied for:

Accessing objects with a specified classification, or

Grouping together and reporting a range of objects with a similar or exact classification, as
specified.

AVEVA NET supports a user-definable multi--level classification system. Classification of objects

can also be applied to create and maintain standard or preferred object templates.

See also ATTRIBUTE, OBJECTS.

Client/Server

Computer architecture in which the users (clients) are connected through a network to a database
(server). The client provides the user interface to the server, to access or maintain data.

The client is typically a personal computer or a workstation performing limited application

processing, whereas the server is typically a file or database server residing on mini or mainframe
with powerful processing capability and extensive data storage capacity.

The server maintains the databases and processes requests from the client to extract data from or
update the databases. The server also controls the application's integrity and security.

See also DATABASE MANAGEMENT SYSTEM, LOCAL AREA NETWORK, STRUCTURED

QUERY LANGUAGE, TRANSMISSION CONTROL PROTOCOL / INTERNET PROTOCOL and WIDE
AREA NETWORK.

Client (in the context of AVEVA NET Portal)

© Copyright 2003 to current year.

7-9 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

The AVEVA NET Portal Dashboard running in Microsoft’s Internet Explorer browser.

Client-side

The machine running the AVEVA NET Portal Dashboard.

Collaboration

Communication between AVEVA NET Portal users (see Online/ Offline Collaboration).

COM API (in the context of AVEVA NET Portal)

An API for populating and querying the AVEVA NET Portal Database that supports both the AVEVA
NET Portal Dashboard and the AVEVA NET Portal Admin Tool (See also .NET API).

COM+

A Microsoft technology that allows the communication of data between servers.

Comment (in the context of VizStream)

The unit of communication in a VizStream online collaboration session.

Comment (in the context of AVEVA NET Portal)

Earlier name for a AVEVA NET Portal Note.

Comment List Control (in the context VizStream)

The VizStream Tree-view gadget that supports an online collaboration session.

Community

The term used to denote an AVEVA NET collection of data, users, groups and permissions. A
community name is a label that a user chooses when logging in to AVEVA NET. There may be a
choice of several on the drop down list on the AVEVA NET login screen. Individual communities may
be located in one physical database or on several different servers.

When accessing one community a user may not simultaneously access the information from
another community from that workplace session.

See ENTERPRISE REPORT MANAGEMENT.

Component

One of the child objects that make up a parent object in a single level. As a component can be
decomposed into next-lower components, it may also be defined as a parent object in its own right.

See also OBJECT, PARENT and SINGLE LEVEL.

Compound Document

Documents can be related to one another in a hierarchical parent-child relationship. The user can
define this relationship as follows: the component document, which also exists as a stand-alone
entity, is part of the parent document (for example, where a circuit diagram is

also used in a maintenance manual).

© Copyright 2003 to current year.

7-10 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Compound document relationships enables the user to create document trees, and provide trace-
ability on document references.

See also DOCUMENT-DOCUMENT RELATIONSHIPS.

Can be Known as FOLDER if separately identified versus a contextual grouping.

See also DOCUMENT and DOCUMENT-DOCUMENT RELATIONSHIPS.

Computer Aided Design (CAD)

The use of computer based tools (applications) to assist in the design, drafting, and physical layout
of mechanical and electronic objects.

Computer Aided Engineering (CAE)

The use of computer based tools to assist in one or more aspects of the object design and
engineering analysis process, such as finite element analysis and mechanism analysis from initial
design to testing.

Computer Aided Manufacturing (CAM)

The use of computer based tools to program, direct and control objection equipment in the fabrication
of manufactured items. CAM includes applications that support manufacturing engineering, such as
NC programming, process planning, factory layout, and simulation.

Computer Aided Software Engineering (CASE)

The use of computer based tools to aid in the software engineering process. CASE tools are used in
software design, database design, requirements tracing, code objection, testing, document
generation and other software development activities.

Computer Output to Laser Disk (COLD)

See ERM

Concession

See WAIVER

Concurrent Engineering (CE)

A systematic approach to the integrated, concurrent design of objects and their related processes,
considering all manufacturing, support and end-use requirements during the design phase of the
object's life cycle.

This approach makes sure that the developer, from the outset, considers all elements of the object
life cycle from conception through disposal, including quality, cost schedule and user requirements.

See also OBJECT LIFE CYCLE.

Configuration

The planned or existing breakdown of an entity by the number, nature, arrangement and interfaces of
its components, to conform to designated functional and/or physical characteristics.

© Copyright 2003 to current year.

7-11 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

The designated functional and/or physical characteristics of the entity (the configuration of the entity)
are determined by the requirements of the entity's end-use. It is thus the configuration of the entity
that makes it what it is, giving it the specific physical, functional and/or other qualitative
characteristics making it suitable for use to satisfy a need.

In the context of Configuration Management such an entity is referred to as an item. The item can be
hardware, software, a process or a function or combinations of these, configured to represent or
achieve an identifiable end-use item.

A configured end-use item can be a singular item like a screw, a valve or a resistor, or a complex
piece of equipment like an aircraft, a complete plant, or a process like brewing beer or performing a
maintenance operation.

See also DOCUMENT, FUNCTIONAL CHARACTERISTICS ITEM and PHYSICAL

CHARACTERISTICS.

Configuration Audit

Configuration audit is the process of verifying an item for compliance with its identified configuration,
as constituted by its associated documentation. Configuration audit is performed through:

Physical configuration audits, and

Functional configuration audits.

See also CONFIGURATION, CONFIGURATION MANAGEMENT, DOCUMENT, FUNCTIONAL

CONFIGURATION AUDIT and PHYSICAL CONFIGURATION AUDIT.

Configuration Control

The process and procedures that manage how changes are proposed, reviewed, approved and
recorded, and then incorporated into an item and its associated documentation.

Change control in AVEVA NET maybe implemented on physical items, tags, virtual items in its
groups, and documents.

Configuration control is a part of overall configuration management, and uses review and release
processes which involve the systematic recording, proposal, evaluation, coordination, approval and
implementation, or rejection of:

Proposed changes to data and/or documentation which underwrite the configuration of items, or

Proposed variations to a configuration item and it's associated data and documentation.

Formal Configuration Control is only performed after approval of an item, its baseline, and/ or the
approval of a document.

The process of configuration control is summarized as follows:

Registration of a change proposal.

Identification of candidate item and/or documents subject to change control.

Performing a change request effects analysis to ascertain which other objects and associated data
are possible candidates for change.

© Copyright 2003 to current year.

7-12 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Performing an impact analysis which quantifies and qualifies the change impact on costs,
schedule, performance, benefits, contracts, etc.

Formal identification of affected prime objects, associated data and documents.

Formal approval to proceed with change implementation.

Identification and tasking of resources to proceed with change implementation.

Expediting, monitoring and reporting of change implementation status.

See also BASELINE, CHANGE, CHANGE EFFECTS ANALYSIS, CHANGE ORDER, DATA,
DOCUMENT APPROVAL, ITEM APPROVAL and MODIFICATION.

Configuration Identification

The act of uniquely identifying an item according to its functional and physical characteristics,
including all it's underwriting data and documents. Configuration Identification includes the following
actions:

Selecting configuration items and non-configuration items,

Determining the types of documentation and data required for each item to completely underwrite
such an item,

Issuing numbers and other identifiers to be affixed to items and documents for unique
identification,

Maintaining descriptive and control attributes associated with items and documents,

Creating a direct association between an underwriting document and an item,

Determining the complete make-up of configuration items,

Establishing baselines for items, and,

Releasing items and their associated data and documentation in terms of defined baselines.

The complete action of Configuration Identification is also known as Object Identification

See also ATTRIBUTE, BASELINE, CONFIGURATION, CONFIGURATION ITEM, DATA,

DOCUMENT, ITEM, ITEM-ITEM RELATIONSHIPS, PHYSICAL ITEM, OBJECT, OBJECT
BREAKDOWN STRUCTURE, OBJECT DATA, VIRTUAL ITEM and VIRTUAL ITEM BREAKDOWN
STRUCTURE.

Configuration Item (CI)

A configuration of hardware, software, firmware, functions and/or processes which, as a complete

entity, is identifiable as an item of which the composition, functional and/or physical characteristics
can be altered. These alterations to the item must be known and controlled for the design,
integration, operational application and logistic support of the item.

A configuration item is identified in AVEVA NET with a prime identifier and a version number.

See also CONFIGURATION, CONFIGURATION CONTROL, CONFIGURATION IDENTIFICATION,

FIRMWARE, FUNCTIONAL CHARACTERISTICS, HARDWARE, ITEM, MODIFICATION, PHYSICAL

© Copyright 2003 to current year.

7-13 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

CHARACTERISTICS, PROCESS, SOFTWARE and VERSION.

Configuration Management (CM)

Configuration Management is a formal engineering discipline with established methods to maintain

the integrity of an object throughout its life cycle. CM involves the application of four fundamental
technical and administrative principles:

Configuration Identification - To identify and document the functional and physical

characteristics of items.

Configuration Control - To control changes to the configuration of items and/or their related data
and documentation.

Configuration Status Accounting - To record and report the status of item identification and
changes to items, data and documents.

Configuration Verification - To verify item configuration and associated data and document
integrity through audit.

See also CHANGE, CONFIGURATION, CONFIGURATION AUDIT, CONFIGURATION CONTROL,

CONFIGURATION IDENTIFICATION, CONFIGURATION ITEM, CONFIGURATION STATUS
ACCOUNTING, DOCUMENT, FUNCTIONAL CHARACTERISTICS and PHYSICAL
CHARACTERISTICS.

Configuration Status Accounting

Configuration Status Accounting is the process of recording and reporting the status of item
identification and changes to items, data and documents. It includes configuration changes and
change implementation status, modification status, deviations and waivers for an item, with
references to supportive data and documentation.

See also BASELINE, CHANGE, CONFIGURATION CONTROL, DEVIATION, MODIFICATION and

WAIVER.

Configuration Verification

See CONFIGURATION AUDIT.

Connection Pooling

A cache of connections between Clients and the Server (a performance optimisation).

Connection String

A set of parameters needed for the AVEVA NET Portal Dashboard or Admin Tool to gain access to a
AVEVA NET Portal Database.

Container

An object with ‘Parent/Child’ relationship to other Objects. Any class of object can be a ‘container’ -
the associations that create the relationship.

Content

In the context of Datasets. A relationship showing the attribute groups, attributes and values

© Copyright 2003 to current year.

7-14 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

managed by a particular dataset.

Content Explorer

The web-part in the bottom-left-hand corner of the AVEVA NET Portal dashboard containing detailed
information about the currently selected object of interest.

Content Folder

An object created by the Import Server and played in the Tree-view corresponding to a folder in a
Staging Area.

Content Viewer

The web-part on the right-hand-side of the AVEVA NET Portal Dashboard where documents are
displayed.

Context

Effectively a namespace. Any AVEVA NET Portal object ID may serve as the Context for any other
object ID.

Continuous Acquisition and Life Cycle Support (CALS)

Copies

See DOCUMENT COPIES AND MASTERS.

Cross Reference

A secondary identifier (number) that can be associated with prime objects, i.e. documents, physical
items and virtual items. The cross-reference type is user-definable. Examples of cross reference
types are:

NATO Number,

National Stock Number,

Catalogue Number,

Company XYZ's Item Number,

ISBN Number, etc.

The user can use any defined cross-reference number to access a primary object in AVEVA NET.
AVEVA NET also maintains cross-references to manufacturers and their numbers allocated to the
object.

See also OBJECT, OBJECT IDENTIFICATION and PRIME IDENTIFIER.

Customization

The acts of modifying or extending an AVEVA NET system by writing additional modules or routines
that are added to, extended or replace standard system functionality.

Dashboard (AVEVA NET Portal)

© Copyright 2003 to current year.

7-15 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

The part of AVEVA NET Portal that a user interacts with, running in a Browser on the Client
machine.

Data

Recorded detail, of any nature, about an object, regardless of the medium or characteristics of the
detail, which is defined, created, stored, maintained and distributed for providing input to man or
machine for interpretation purposes.

See also DOCUMENT, DOCUMENT METADATA, ITEM, ITEM METADATA, METADATA, OBJECT,
OBJECT IDENTIFICATION and OBJECT DATA.

Data Compression

Encoding of electronic data to take up less storage space. For example, short names in fixed length
fields waste a lot of space. A simple method called run length encoding converts the spaces into a
code that indicates how many blanks follow.

Data compression can be performed by two major techniques, namely statistical or dictionary. The
Huffman coding and LZW (Lempel-Ziv-Welch) methods are widely used examples of each
respectively.

See also DECOMPRESS.

Data Cleansing

The process of checking and correcting data to maximise its useful information content.

Data Validation (in the context of AVEVA NET Portal)

Checks carried out by the Import Server with the help of optional user-definable Callout Code.

Database Management System (DBMS)

Software that controls the organization, storage, retrieval, security and integrity of data in a
database.

It accepts requests from the application and instructs the operating system to act in accordance with
requests involving the input of, change to, deletion of, reading of, manipulation and transferring of
appropriate data.

See also CLIENT/SERVER and STRUCTURED QUERY LANGUAGE.

Dataset

A collection of attributes and their values relating to, and associated with an object in AVEVA NET.
The dataset is contained in a specialized Document which provides versioning and default
configuration & values.

See also DOCUMENT, DOCUMENT METADATA, ITEM, ITEM METADATA, METADATA, OBJECT,
OBJECT IDENTIFICATION and OBJECT DATA.

Dataset (AVEVA NET Portal)

A collection of arbitrary name-value attributes stored as an XML string in the AVEVA NET Portal
database.

© Copyright 2003 to current year.

7-16 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Database Management System (DBMS)

Database Management System – such as Oracle or Microsoft’s SQL Server

Decompress

To restore compressed data back to its original size.

See also DATA COMPRESSION.

Design

The process of defining and documenting the architecture, components, interfaces and other
physical and functional characteristics of a system or component to satisfy an enduse.

See also LIFE CYCLE.

Design (DGN)

A drawing format output by PDS/ Microstation

Deviation

A written authorization, granted before the manufacture of a physical item, to depart from a particular
performance or design requirement of a specification, drawing or other document, for a specific
number of units or a specified period of time.

A deviation event is further characterized by the following:

It is directly associated with a serialized item.

It has a specified effectivity.

A deviation does not warrant change to a baseline.

A deviation record will be maintained by AVEVA NET as part of the item's build history.

See also AS-BUILT CONFIGURATION, BASELINE, BUILD HISTORY, CHANGE, CONFIGURATION

STATUS ACCOUNTING, EFFECTIVITY, ITEM BASELINE, PHYSICAL ITEM and SERIALIZED ITEM.

Distribution

The action taken in transmitting a document or set of documents to one or more persons. Generally
copies of documents on any media are distributed for a defined reason and tracked.

See also DOCUMENT COPIES, CIRCULATION, REQUISITIONS, TRANSMITTALS.

Distribution List

A standard list of persons and/or organizational units which is associated with a document(s), for the
distribution or circulation of document copies. The distribution list is user-definable and re-usable.

See also DOCUMENT, DOCUMENT COPIES AND MASTERS, ORGANIZATIONAL UNIT and
PERSON.

Document

© Copyright 2003 to current year.

7-17 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

A document is an identified collection of data, grouped and structured so that it can convey meaning
within a context to man or machine. This collection of data is constituted by the document content

The content may be of a physical or electronic nature embedded and preserved in an associated
media such as paper, a computer data base, solid-state device, microfilm, optical devices, etc.

The preserved data is used interchangeable with the term information, or document content, or
record.

The document object is identified for the purpose of controlling the promulgation of the object to man
or machine, where the embedded collective data is applied in the process of interpretation.

The document object is represented in AVEVA NET by the document master record.

As managed entities in AVEVA NET, documents are identified in accordance with the conventions of
document numbering, revision, and title. The degree of document change control is determined by
the user.

A document object may exist with or without reference to the document source.

See also CONFIGURATION, DATA, FUNCTIONAL CHARACTERISTICS, ITEM, OBJECT, OBJECT

IDENTIFICATION, PHYSICAL CHARACTERISTICS, OBJECT DATA and REVISION.

Document Approval

The action taken by a user to approve a document record maintained by AVEVA NET. Only
documents identified as subject to Change Control can be approved. Document approval implies the
locking of document metadata to change.

A parent document containing component documents in a Contained In relationship can only be

approved when the component documents are also approved.

An approved document's metadata can only be changed through authorized configuration control
procedures.

See also CHANGE, COMPONENT, CONFIGURATION CONTROL, DOCUMENT, DOCUMENT-

DOCUMENT RELATIONSHIP, DOCUMENT METADATA, METADATA and PARENT.

Document Change Record (DCR)

Document Class

A document class represents for a specific document type, or family of document types, a set of
common attributes, permissions and required relationships for the document with other objects
including documents, as well as systems actions to be performed during the life cycle of the
document.

The document class serves the following purposes:

It depicts the properties that must be specified, as well as the methods for create, maintain and/or
control, associated with the document type.

The class acts as the template from which an instance of a document master record iscreated.
The instance contains the actual data associated with the specific document.

Document classes can be represented in a hierarchical form, which may allow complete orselective

© Copyright 2003 to current year.

7-18 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

inheritance of class properties from parent to child.

See also CLASSIFICATION.

Document Content

The ‘logical’ document, not the physical ‘file’ of that Document; all AVEVA NET Portal document
classes must be sub-classed from the class DOCUMENT CONTENT.

Document Copies and Masters

A document copy is an object, which represents the existence of a real-world managed document in
a specific media and location.

The document copy object may be described and controlled by attributes such as the copy number,
status of the copy, etc.

A singular document object may have many document copies in different media, i.e. electronic file,
paper and microfiche.

Real world managed document objects are stored and distributed as document copies.

A master document is the source from which copies of the document are made. When a document
is affected by change, the master document will be updated.

AVEVA NET allows the user to identify only one master document, but many copies. The user can
define the media for a document master as well as for each copy. For example, the master
document can be kept as an electronic file, copy one of the document as a paper copy and copy two
as microfiche. A document master and its subsequent copies can be allocated to locations, to
identify where the document is kept.

Only copies of a document can be distributed. The availability of document copies is managed by
AVEVA NET, i.e. whether a copy has been issued, is available for distribution, or whether it has
been lost or destroyed.

See also CHANGE, DISTRIBUTION LIST, DOCUMENT, DOCUMENT MANAGEMENT and

LOCATION.

Document-document Relationship

Documents can be related to one another in a hierarchical parent-component relationship. The user
can define this relationship as follows: the component document, which also exists as a stand-alone
entity, is part of the parent document (for example, where a circuit diagram is also used in a
maintenance manual).

Document-document relationships enables the user to create document trees, and provide trace
ability on document references.

AVEVA NET warns the user when a parent or component document is identified as being affected by
change of all the related parents and components during the change effects analysis.

When a document has been defined with components in a Contained In relationship, the following
rules apply:

The parent document cannot be approved unless the component documents are also approved.

© Copyright 2003 to current year.

7-19 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

When a component document is under change, the parent document will also be under change.

When a component document's revision is stepped, the parent document's revision must also be
stepped.

See also CHANGE, CHANGE EFFECTS ANALYSIS, COMPONENT, CONFIGURATION CONTROL,

DOCUMENT, DOCUMENT APPROVAL, DOCUMENT LINKS, PARENT and REVISION.

Document Folder

A virtual item object that functionally represents a subject through a collection of documents - the
document folder is not regarded as a document in itself.

A document folder is created by the classification of a virtual item to such effect.

See also VIRTUAL ITEM.

Document Holder

Denotes the instance of a document copy issued to a user. Such user can be man or machine.

Identification of the holder may include the holder location, the document copy record and the reason
for holding the document.

See also DISTRIBUTION.

Document Indexing

The recording of the document prime identifier and associated attribute values as metadata that
represents the document master record, the purpose thereof to uniquely and unambiguously identify
the specific document.

The document class determines the attribute set and range of attribute values to be maintained as
indexing data.

The sum of defined attributes and its specified values to the document constitute the index to the
document object which is applied in describing, searching, finding and controlling the document.

See also IDENTIFICATION, ATTRIBUTES.

Document Management (DM)

The discipline, associated processes and infrastructure that provide for secure and controlled receipt,
storage, access, maintenance and distribution/promulgation of all data sets managed by AVEVA
NET. Document management is the interface between users and object data, to provide controlled
and optimum access to object data.

See also DATA, DISTRIBUTION LIST, DOCUMENT, DOCUMENT APPROVAL, DOCUMENT

COPIES AND MASTERS, METADATA, OBJECT DATA and OBJECT DATA MANAGEMENT.

Document Master Record (DMR)

Represents the metadata instance of a real-world managed document. The instance contains actual
data about the document object in accordance with the document class. The document master
record represents all indexing and control data about the document object.

© Copyright 2003 to current year.

7-20 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

See also DOCUMENT, DOCUMENT METADATA, ATTRIBUTES.

Document Media

Document media denotes the format, method and device whereby document content is embedded for
preservation, access and promulgation.

Format may include video, voice, graphics or text.

Method may include mechanical or electronic in digital or analogue form.

Device may include optical, magnetic, solid state, paper, film or other devices capable of
preservation of document content.

Document media is directly associated with the document copy whereby the document copy it
denotes the instance of the document content in a media at a location.

See also DOCUMENTSOURCE, ELECTRONIC SOURCE.

Document Metadata

Document metadata primarily consists of the following:

A document number which, together with the document revision, constitutes the document's prime
identifier.

Descriptive attributes, e.g. the title of the document.

Control attributes, e.g. whether the document is subject to change control.

Document components identified in a Contained-in relationship.

Document cross-references.

When a document is approved, the metadata cannot be changed unless the document is declared
as Under Change, through defined configuration control procedures.

Secondary document metadata consists of:

Document responsibilities, e.g. author, approver, etc.

Document location.

Document copies.

See also ATTRIBUTE, COMPONENT, CONFIGURATION CONTROL, CROSS REFERENCES,

DATA, DOCUMENT, DOCUMENT APPROVAL, DOCUMENT COPIES AND MASTERS,
DOCUMENT-DOCUMENT RELATIONSHIPS, LOCATION, METADATA, OBJECT, OBJECT
IDENTIFICATION, PRIME IDENTIFIER, RESPONSIBILITIES and REVISION.

Document Links

Document links define a link between documents in one of two ways:

Propagated from - the component document is derived from the parent document (for example,

© Copyright 2003 to current year.

7-21 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

where a lower level specification document is derived from a higher level specification document).

Referenced by - the component document is referenced in the parent document.

See also DOCUMENT, DOCUMENT-DOCUMENT RELATIONSHIP and ITEM LINK.

Document Number

A prime identifier associated with the document object for the purpose unambiguously identifying the
specific object as a singular entity. The prime identifier is unique to the document object and cannot
be duplicated.

The document number may be allocated manually by the user, or automatically by the system. The
document number may be visible or transparent to the user.

The format of the document number is irrelevant and bears no significance to applied business logic.

The document number may consists of several data fields which in combination constitutes the
unique identifier for the document, i.e. document reference + document revision.

See also IDENTIFICATION. ATTRIBUTE, DOCUMENT.

Document Object Model (DOM)

Document Object Model; software presenting an object oriented API to an XML document

Document Permissions

As per the defined requirements of the user, suitable rights allocated to the user by the system
administrator to access and/or use system functions in document creation, maintenance and/or
usage.

This includes access to the document master record and/or -content as well as transactions and/or
applications which allow the user to add, change, delete and/or view metadata or document content.

Detailed granularity of permissions may be collected into categories of permissions, e.g. edit
includes the ability to add a document record, edit attributes and delete a document record.

A user permission profile is usually directly associated with the document class.

See also PERMISSIONS, PERMISSIONS TEMPLATE, SECURITY CERTIFICATE.

Document Permission Template

A pre-defined permission set of a typical user profile as applicable to a specific document class.
Upon election of a document to the class, the permissions granted to user for the specific document
will default to the document permission template for the class.

See also PERMISSIONS, PERMISSIONS TEMPLATE, SECURITY CERTIFICATE.

Document Plan

The document plan defines the documentation requirements for a particular object. It identifies the
documents and the CI which it underwrites, with respect to the concluding baseline for the specified
program/project phase.

© Copyright 2003 to current year.

7-22 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

It can also include the identification of responsible persons or organizational units with planned dates
for completion.

See also DOCUMENT, ORGANIZATIONAL UNIT, PERSON and OBJECT.

Document Repository (in the context of AVEVA NET Portal)

A set of folders storing user documents (usually after reformatting) so that they can be accessed by
the AVEVA NET Portal Server for display in the AVEVA NET Portal Content Viewer.

Document Requisition

A request for a document or set of documents to be transmitted to one or more persons. Only copies
can be distributed for a defined reason and can be associated to a distribution list. Holders (persons)
are linked to the documents transmitted.

See also DISTRIBUTION, DOCUMENT COPIES, HOLDERS

Document Revision

See REVISION.

Document Security Certificate

The defined access and permission record created for a specific document. The document security
certificate can result from the document permission template, or be manually defined by the user, or
a combination of thereof.

Every document has a security certificate which regulates per user the overall rights of access,
document master record and/or -content maintenance.

See also PERMISSIONS, PERMISSIONS TEMPLATE

Document Source

An identified and controlled instance of the document media which is stored for the purpose of
preserving the document, and/or applied in the process of creating and/or copies of the document.

The document source is described and controlled by its attributes, i.e. the document copy may be
identified as the master copy an electronic media in a word processor format.

All document copies, replications and files, regardless of media and format, are

spawned from the document source.

For an approved and revision controlled document, document source will be replicated and applied for
the creation of the new revision document - approved document source is never changed.

See also DOCUMENT MEDIA.

Document Source Location

A reference to the storage/preservation device and its location to which the document source is
embedded.

See also DOCUMENT MEDIA, LOCATIONS.

© Copyright 2003 to current year.

7-23 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Documentum

A commercial DBMS sold as a ‘document vault’.

Dumb Document

A document with no ‘hotspots’ and so does not support picking or highlighting.

dwg File

A drawing format output by AutoCAD.

Effectivity

An user-specified value, typically identified as a date or serial number(s), which denotes the
applicability of a specific condition on an item or document. Examples are:

The effectivity date of a document or item, i.e. when it is suitable for use,

The applicability of a waiver or deviation, or

The implementation of a modification on a selected serialized item.

See also DEVIATION, DOCUMENT APPROVAL, ITEM APPROVAL, MODIFICATION, SERIALIZED

ITEM and WAIVER.

E-mail

A service that allows users and organizations to communicate electronically. It can include
distribution of formatted documents and messages to mailboxes (special computer files) and
notifying users of incoming mail. AVEVA NET uses e-mail to route action notifications.

See also LOCAL AREA NETWORK and WIDE AREA NETWORK.

Engineering Change Order (ECO)

See CHANGE ORDER.

Engineering Change Proposal (ECP)

See CHANGE ORDER and CHANGE REQUEST.

Enterprise Integration Toolkit (EIT)

Enterprise Integration Toolkit, an earlier name for AVEVA NET Portal

Enterprise Information and Workflow Model (EIWM)

Enterprise Information and Workflow Model – the information Model (strictly speaking the

underlying Meta Model) on which AVEVA NET Portal is based.

Enterprise Information and Workflow Model (EIWM) Schema

The XML schema for files that the AVEVA NET Portal Import Server is able to process; can be
exported by the Admin Tool.

© Copyright 2003 to current year.

7-24 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Electronic Document Management

EDM, a synonym for Object Data Management of electronic media.

See also DOCUMENT MANAGEMENT, OBJECT DATA MANAGEMENT.

Electronic Source

This term refers to any digital media that represents the document object identified in the EDMS.
This source can consist of one or many files and can also contain different file formats to support
rapid access for the consumer.

Also known as, MEDIA OBJECTS; FILES;

See also DOCUMENT MANAGEMENT, OBJECT DATA MANAGEMENT.

Element (in the context of XML)

A item of information introduced by an element <name> in angle brackets and terminated by </
name>.

Engineering Workstation

See WORKSTATION.

Enterprise

A business entity which is related by a common interest or objective in a object, or group of objects,
and associated business processes. An enterprise may also logically include a network of
subcontractors involved in the common object.

See also PROCESS, OBJECT and OBJECT DATA MANAGEMENT.

Enterprise Change Notice (ECN)

Enterprise Change Request (ECR)

Enterprise Explorer

The web-part in the top-left-hand corner of the AVEVA NET Portal dashboard mainly occupied by the
Tree-view.

Enterprise Report Management (ERM)

See also COLD.

Equipment List

A Process Industry document providing a definitive list of Project Equipment and their identifiers.

Equivalents

A term which denotes the validity of exchanging an identified physical item with another identified
physical item. There are three types of equivalent:

Interchangeable item - where an interchangeable item is equivalent in fit, form and function to
the item for which it is exchanged.

© Copyright 2003 to current year.

7-25 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

It can be used without selection of fit or performance, or without alteration to the item or adjoining
items, except for adjustment.

Replacement item - where a replacement item is equivalent in function but differs physically from
the item for which it is exchanged. Installation of the replacement item may require additional
drilling, reaming, cutting, etc. to the item or adjoining items.

Substitute item - where a substitute item can only be used under specified conditions or in
particular applications, without alteration to the item or adjoining items.

See also FIT, FORM AND FUNCTION and PHYSICAL ITEM.

Facility

A ‘logical’ or design object – such as an object in PDMS that is ’fulfilled by’ a physical Asset in the
built plant.

Factory Acceptance Test (FAT)

Factory Acceptance Test – a test carried out at the supplier’s premises (c.f. SAT).

Feature Code (Licensing)

An AVEVA defined code for a separately priced product feature licensed using FlexLM.

File

These are the basic components of the document. A file may be a TIFF image, CAD file, HTML,
PDF, Word document, AVI sound bite, movie or software source code, for example.

Note: At this level there is no mention about files, since a file is a type of file with a relationship to
another file. Note, the use of page as a description for this object is not appropriate since a word file
may contain multiple pages, or a multi-page TIFF file is a single file with multiple image pages.

A physical representation of a Document (e.g. in a file) as compared with the logical content of the
document. AVEVA NET Portal file objects are usually of class FILE.

See also DOCUMENT SOURCE, DOCUMENT MEDIA.

Find (AVEVA NET Portal)

A simple query mechanism in the Enterprise Explorer web part for finding objects by ID and/ or Class
with optional % and _ wildcards (See also Advanced Find).

Fit

The ability of a physical item to physically interface or interconnect with or become an integral part of
another item.

See also FIT, FORM AND FUNCTION, ITEM and PHYSICAL ITEM.

Fit, Form and Function

Fit, form and function imply the functional and physical characteristics of an item as an entity,
covering all characteristics of the elements making up the item.

© Copyright 2003 to current year.

7-26 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

See also CONFIGURATION ITEM, FIT, FORM, FUNCTION, FUNCTIONAL CHARACTERISTICS,

ITEM and PHYSICAL CHARACTERISTICS.

Folder

A folder can be regarded in two different ways:

Firstly as a 'parent' document with the same characteristics as a regular document, but also
containing relationships to 'child' documents (Compound Document).

Secondly as a means of grouping documents for 'contextual' purposes (virtual entity).

Also known as, DOCUMENT; VIRTUAL ITEM; SHORTCUT.

Form

The shape, size, dimensions, mass, weight, and other visual parameters which uniquely characterize
a stand-alone physical item. For software, form denotes the language and media.

See also FIT, FORM AND FUNCTION, ITEM, PHYSICAL ITEM and SOFTWARE.

Folder (AVEVA NET Portal)

A object serving as container – by virtue of its associations to other objects.

Folder.vnet file

An XML file in a Staging Area folder supplying default metadata for all the files in that one folder.

Free Text Retrieval (FTR)

The ability to create an index based on the content of documents. This function allows text string
searches to be made in conjunction with regular indexing methods.

See also INDEX, ATTRIBUTES.

Fullname (in the context AVEVA NET Portal)

A unique identifier for a AVEVA NET Portal object complete with the Context e.g. ContextID|ObjectID
(c.f. Simple ID).

Full Text Search

A search mechanism supported by Sharepoint for the documents it has indexed.

Function

Virtual Items are applied in AVEVA NET to represent functions.

See also FIT, FORM AND FUNCTION, FUNCTIONAL CHARACTERISTICS, ITEM, PROCESS,
VIRTUAL ITEM and TAG.

Functional Characteristics

Measurable performance parameters and design constraints, including operational and logistic
parameters and their respective tolerances, that quantify the behaviour of an item within its specified
operational environment. Functional characteristics include all performance parameters, e.g. range,

© Copyright 2003 to current year.

7-27 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

speed, reliability, maintainability, safety, etc.

See also FIT, FORM AND FUNCTION.

Functional Configuration Audit (FCA)

The formal examination of the functional characteristics of a configuration item or process, before
acceptance, to verify that the item or process has achieved the requirements specified in its
functional and allocated configuration documentation.

See also CONFIGURATION ITEM, CONFIGURATION MANAGEMENT, DOCUMENT, FUNCTIONAL

CHARACTERISTICS and PROCESS.

Functional Item

See VIRTUAL ITEM.

General Arrangement (GA)

General Arrangement Drawing output by PDMS DRAFT. Can be made intelligent by running special
AVEVA NET Portal Appware.

Generic Baseline

Generic Baselines give the user the flexibility to define what objects should be included in the
baseline, i.e.

a) what types of objects

b) how many levels of object links for each object

c) according to what rules (e.g. "Approved" only or also "Not Approved")

When created, a Baseline is a Document containing a list of objects that were found as a result of
following the rules in the Baseline Definition. All the objects are shown as they were at the time the
Baseline was created, including Non Approved objects (which may have changed after the snapshot
was taken)

See also BASELINE, BASELINE DEFINITION

Graphical User Interface (GUI)

A user interface to a computer program that includes windows, menus, dialogue boxes, icon palettes
and other point-and-select command selection methods, and the use of graphics to present and
manipulate data.

GUIs contrast with text and forms based user interfaces found on "dumb" terminals and in mini and
mainframe based computing systems.

Group

An identified group of users who are designated through a range of specified permissions to create,
maintain and/or use information records and/or information objects of specific types within the
specified scope of a business process.

A group is characterized by a singular or combination of requirements as below:

© Copyright 2003 to current year.

7-28 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Repetitive creation, maintenance and/or use of information records and/or objects of the same type
by a specific line-of-business application.

The user within the community allocates specific permissions to the community object which,
unless specified otherwise, allow the inheritance of such permissions.

User-interaction to information records and objects specific to the community, i.e. user-interfaces,
queries and reports.

Exclusive ownership and/or access to information records and objects, or specified sharing thereof
with other communities.

See also USER GROUP, PROJECTS.

Handle (DB)

An internal system ID possessed by every AVEVA NET Portal Object, Class, Association etc.

Handover

The stage in a project when the plant and its documentation are passed to the Owneroperator: point
in a project where AVEVA NET Portal has much to offer.

Hardware

Synonym for physical items, such as plant equipment, support equipment, weapons, aircraft, ships,
tools, computers, vehicles, and their components such as mechanical, electrical, electronic,
hydraulic and pneumatic parts. Computer software and documentation are excluded.

See also DOCUMENT, ITEM, PHYSICAL ITEM and SOFTWARE.

Horizontal Relationship

A term used in the context of AVEVA NET to depict a parent/component relationship of either
physical or virtual items, i.e. the physical breakdown of a object for physical items, or the functional
breakdown of a object for virtual items.

AVEVA NET only allows items of a specific kind, i.e. either physical items or virtual items, to be
related in Horizontal Relationships. Relationships between virtual items and physical items are
created through Vertical Relationships.

See also COMPONENT, ITEM-ITEM RELATIONSHIPS, PARENT, PHYSICAL ITEM,

VERTICAL RELATIONSHIP and VIRTUAL ITEM.

hit File

A file containing identifiers and X, Y co-ordinates used to make an otherwise ‘dumb’ document
‘intelligent’.

Hotspot

Part of a document or drawing that is pick-able and highlight-able.

Hyper Text Mark-up Language (HTML)

© Copyright 2003 to current year.

7-29 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

The format used to transmit information between the Web Server and Browser on the Client

machine.

Identifier (ID)

Every AVEVA NET Portal Object has at least one Identifier containing an ID, optionally a Context,
and optionally a Revision name/number and a longer descriptive name.

Illustrated Parts Catalogue (IPC)

Import Controller

Part of AVEVA NET Portal supporting the user interface that the user interacts with to launch and
monitor an import session; connects to a AVEVA NET Portal Import Server.

Import Engine

A earlier name for the AVEVA NET Portal Import Server.

Import Package

Definition of a repeatable Import unit linking a specified AVEVA NET Portal Database, Staging Area
and user preferences.

Import Server

Software that reads XML files to populate the AVEVA NET Portal database and processes user
documents and stores them in the AVEVA NET Portal Document Repository.

Incremental Update

An update to the AVEVA NET Portal database involving as little as one new or modified file in the
Staging Area.

Installed Item

A concept associated with the definition of a tag. It identifies the specific physical item that has been
installed to fulfil the required function designated to the tag.

The installed item can only be one of the designated preferred physical items as denoted by the tag
definition.

See also PREFERRED PHYSICAL ITEM and TAG.

InstallShield

Third party software used for installing AVEVA NET Portal.

Instrument List

A Process Industry document providing a definitive list of Instruments in the project and their
identifiers.

Intelligent Document

A user document supporting picking and highlighting in the AVEVA NET Portal Dashboard (possibly

© Copyright 2003 to current year.

7-30 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

after reformatting).

Internet Information Service (IIS)

Internet Information Services – the Microsoft system running on the AVEVA NET Portal Server
supporting web sessions.

Internet Information Service (IIS) Reset

Used to throw clients off the server and re-initialise some web services (may fix AVEVA NET Portal if
all else fails).

Internet Information Service (IIS) Timeout

Automatically termination of a connection between Client and Server. By default this is set to 20
minutes.

Intranet

A set of interconnected machines supporting web access but not visible to the wider Internet.

Integrated Project Execution (IPE)

A sample AVEVA project; one of the AVEVA NET Portal test Staging Areas containing documents
and XML files.

International Standard (ISO) 15926

An International Standard that is the basis of the information model used in AVEVA NET Portal.

Issued Data

Data for browsing in the AVEVA NET Portal Dashboard (c.f. Working data).

Item

A non-specific term used in AVEVA NET to denote any system, subsystem, set, group, unit,
assembly, subassembly, part, accessory, process, service, function, tag, etc.

AVEVA NET manages two types of items, namely Physical Items and Virtual Items. See also
CONFIGURATION ITEM, FIRMWARE, HARDWARE, ITEM CLASSIFICATION, ITEM-ITEM
RELATIONSHIPS, OBJECT, OBJECT IDENTIFICATION, PHYSICAL ITEM, SOFTWARE, TAG and
VIRTUAL ITEM.

Item Approval

The action taken by a user to approve an item record maintained by AVEVA NET. Item approval
implies the locking of item metadata to change. An approved item's metadata can only be changed
through authorized configuration control procedures.

See also CHANGE, CONFIGURATION CONTROL, ITEM, ITEM METADATA and METADATA.

Item Baseline

An item baseline represents a complete identified item on a single level. AVEVA NET defines and
controls an item baseline through the identification of a baseline document, which represents the

© Copyright 2003 to current year.

7-31 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

complete configuration of the item.

An item baseline can only be created if the item is approved, and will only include approved
documents related to the item.

Approval of the item baseline document constitutes the declared configuration of the item, and any
subsequent changes to the item metadata or documents covered by the baseline will be subject to
configuration control. An approved item baseline constitutes Item Release.

See also BASELINE, CONFIGURATION CONTROL, CONFIGURATION IDENTIFICATION, CROSS

REFERENCE, DATA, DOCUMENT, ITEM, ITEM APPROVAL, ITEM METADATA and SINGLE
LEVEL.

Item Batch Number

See BATCH NUMBER and SERIALIZED ITEM.

Item Classification

See CLASSIFICATION.

Item Installed Position

A serialized item's functional position relative to an identified serialized parent item.

Item-item Relationships

The hierarchical relation between items in a parent-component relationship to depict the configuration
of the parent item, or the items associated with it. Three types of item-item relationships are
supported by AVEVA NET:

Horizontal relationships between items. For physical items, this denotes a object breakdown
structure and, for virtual items, a functional or process breakdown.

Vertical relationships which denote the relation of a virtual item with a physical item.

Item links which denote the relationship of a physical item to another item, other than for defining
a configuration.

See also CONFIGURATION, HORIZONTAL RELATIONSHIP, ITEM, ITEM LINK, PHYSICAL ITEM,
OBJECT BREAKDOWN STRUCTURE, VERTICAL RELATIONSHIP, VIRTUAL ITEM and VIRTUAL
ITEM BREAKDOWN.

Item Link

A user-definable item-item relationship. This item-item relationship does not represent the physical
configuration of a parent item with its component item (as is the case with a object breakdown
structure), but is the association of one physical item to another physical item.

Typical examples of this relationship are:

Connected To, depicting the physical connection of a pipeline to, for example, a pump.

Compiler, identifying the compiler application for a software item.

Test Equipment, identifying the test equipment required for a hardware item.

© Copyright 2003 to current year.

7-32 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Tools, Jigs and Fixtures, identifying the tools, jigs and fixtures required for the fabrication of a
hardware item.

Equipment Schedules, identifying the range of items required for a specific main equipment to
perform a specific mission.

See also ITEM-ITEM RELATIONSHIPS, ITEM METADATA, PHYSICAL ITEM and OBJECT
BREAKDOWN STRUCTURE.

Item Metadata

Item metadata primarily consists of the following:

An item number which, with the item version, forms the item's prime identifier,

Descriptive attributes, e.g. the description of the item and classification,

Control attributes, e.g. whether the item is classified as a configuration item,

Item component references,

Item cross references,

Item links.

When an item is approved, the above metadata cannot be changed unless the item is declared as
Under Change through defined configuration control procedures.

Secondary item metadata consists of:

Item responsibilities, e.g. designer, approver, etc.

Item location.

See also ATTRIBUTES, CHANGE, COMPONENT, CONFIGURATION CONTROL, CROSS

REFERENCES, DATA, ITEM, ITEM APPROVAL, ITEM LINK, LOCATION, METADATA, OBJECT,
OBJECT IDENTIFICATION, PRIME IDENTIFIER and RESPONSIBILITIES.

Item Release

See ITEM BASELINE.

Item Serial Number

See SERIALIZED ITEM.

JavaScript

One of the languages used on the Client-side.

Keywords

One or many named attribute(s) that can be allocated to an object for the purpose of collectively
grouping or tagging for query purposes.

See also ATTRIBUTE, OBJECT

© Copyright 2003 to current year.

7-33 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

KKS

International standard covering the structure of Identifiers of Process Industry assets and documents.

Legacy System

In-place computing and application systems that exist within an enterprise to perform defined
functions and tasks.

Examples of legacy systems are a Financial Management System, Materials Requirement Planning,
Inventory Management, Maintenance Management, Computer Aided Design, etc. Most legacy
systems depend on data provided by Object Data Management for their function.

See also COMPUTER AIDED DESIGN, ENTERPRISE, MATERIALS REQUIREMENT PLANNING,

OBJECT DATA MANAGEMENT and OBJECT DATA MANAGEMENT.

License Demon

Licensing software unique to a Company using FlexLM.

License Manager

AVEVA code built on FlexLM to implement licensing.

Life Cycle

A generic term covering all phases of acquisition, operation and logistic support of an object,
beginning with concept definition and continuing through disposal of the object.

A object's life cycle is broken down into:

Conceptual phase,

Design and development phase,

Production phase,

Deployment, operational and support phase, and

Disposal.

See also DOCUMENT, ITEM and OBJECT.

Line List

A Process Industry document providing a definitive list of pipelines / piping segments and their
identifiers.

List Gateway

Unreleased AVEVA NET Portal software for converting data held in spreadsheet form to the XML
format that can be processed by the AVEVA NET Portal Import Server.

List - Parts

See PARTS LIST.

© Copyright 2003 to current year.

7-34 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

List - Tags

See TAGS LIST.

Local Area Network (LAN)

Communication facilities allowing locally connected computer systems, workstations and terminals
to interact. Ethernet is the dominant LAN for workstations.

See also CLIENT/SERVER, WIDE AREA NETWORK and WORKSTATION.

Localisation

The process of converting text to a local language – not yet attempted for AVEVA NET Portal.

Location

A location is an identifiable entity in AVEVA NET that can be associated with an object to denote its
physical position. The location can be a site, area, place or spot where the object is installed,
stored, deployed, etc. Locations can be allocated to the following objects:

Persons,

Organizations,

Physical Items,

Virtual items (in their groups),

Documents,

Serialized items,

Tags.

Locations can be structured in a hierarchical manner through parent-component relationships to

denote, for example:

The complete geographical breakdown of a plant, or

The installed positions of maintainable items in main equipment.

The user can classify locations to denote the type of location, such as Document Location, Item
Installed Position, etc.

See also COMPONENT, DOCUMENT, ORGANIZATION, PARENT, PERSON, PHYSICAL ITEM,

SERIALIZED ITEM, TAG, VIRTUAL ITEM and VIRTUAL ITEM GROUP.

Main Equipment

A physical item which, as a stand-alone entity, performs an end-function to achieve the objectives of
a defined mission. Main equipment can have the following characteristics:

It is a complete composite system which can be decomposed into subsystems and lower
identifiable and maintainable physical items, and/or

It is serialized with serialized components, and/or

© Copyright 2003 to current year.

7-35 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

It is a prime asset or inventory item, and/or

It is an end-use item which is manufactured, deployed and maintained.

See also ITEM, PHYSICAL ITEM, SERIAL NUMBER, SERIAL STRUCTURE and SERIALIZED ITEM.

Markup

The process of adding graphics and text to an existing document; only supported in AVEVA NET
Portal for documents that have been converted to VizStream Format. See ANNOTATE.

Master Record Index (MRI)

A controlled index of data, including number, titles and issue status of all configuration identification
documentation, which is required to adequately reflect the defined identification of an item.

See also CONFIGURATION IDENTIFICATION.

Materials Management (MM)

Materials Requirements Planning (MRP)

A methodology and system used to plan and manage manufacturing operations. The BOM for
objects released to manufacturing is a key input to an MRP System Database.

See also BILL OF MATERIAL.

Menuset

A ‘root’ node collection of BreakdownNodes in the tree-view, linked to a ‘Top Object’. Which

Menuset is displayed is dependent on the current User Role.

Metadata

Data pertaining to an object which is stored, created, manipulated, controlled and made available to
users for the purpose of describing, finding and controlling the object.

Metadata can be recognized, interpreted, manipulated by the management system.

Metadata includes identifiers and attributes associated with objects, for example, a drawing number
and the title is metadata about a drawing.

This definition differs from that used by information systems professionals as a definition of a
databases underlying schema.

See also ATTRIBUTE, DATA, OBJECTS and OBJECT DATA.

MetaModel

The structural elements of an information model as contrasted an actual information containing

model. Objects, Classes, Associations and Attributes are the main elements of the AVEVA NET
Portal/ EIWM MetaModel.

Microsoft Data Access Components (MDAC)

Microsoft Data Access Components. (AVEVA NET Portal depends on the right version being

© Copyright 2003 to current year.

7-36 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

installed).

Micro-Server

Portable Server the size of a book used for AVEVA NET Portal demonstrations.

Microsoft Installer (MSI)

Microsoft Installer a simple utility for installing software.

Microsoft MergeMSM

Microsoft Merge Module – a mechanism for delivering a set of software components as one unit.

Microsoft XML (MSXML) 4

Microsoft XML parser Version 4 used by AVEVA NET Portal.

Modification

The act of physically changing the approved configuration of an established item, i.e. main equipment
and/or main equipment components which have been manufactured, deployed and/or supported.

A modification alters the functional and physical characteristics of the item, and can be done

for following reasons:

As a design deficiency corrective action, i.e. to improve safety, reliability, maintainability, etc., or

To change the characteristics of the item to make it more suitable for a specific mission.

Modification to an item can impact directly on the following:

Functional and/or physical interfaces with other items,

Data underwriting the configuration, use and support of the item,

Infrastructure, i.e. persons, organizations, equipment and other facilities employed in the use and
support of the item,

Spares supply and holding.

A modification can only be made through the formal procedures of configuration control.

A modification event is further characterized by the following:

It is directly associated with a serialized item,

It has a specified effectivity,

It warrants changes to a baseline through formal configuration

See also BASELINE, CHANGE, CHANGE ORDER, CONFIGURATION, CONFIGURATION

CONTROL, CONFIGURATION ITEM, EFFECTIVITY, FUNCTIONAL CHARACTERISTICS, MAIN
EQUIPMENT, ORGANIZATION, PHYSICAL CHARACTERISTICS, OBJECT DATA and SERIALIZED
ITEM.

© Copyright 2003 to current year.

7-37 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Modification Order (MO)

See CHANGE ORDER.

Molecular Template

A collection of Atomic Templates.

Microsoft Data Engine (MSDE)

Free to use version of Microsoft SQL Server (with a limitation on the number of concurrent

connections).

Name (in the context of AVEVA NET Portal)

The longer descriptive name that is an optional element of a AVEVA NET Portal Identifier.

Name-Value Pairs

Simple un-typed string attribute values.

Named Relationship

An object relationship where the relationship is described by one or more attributes and its

values.

For relationship created between objects, it is necessary to identify the type of relationship.

When objects of the same kind are related, a default relationship type may apply over the complete
relationship continuum, i.e. physical items related in parent child relationships through multi-level
may be termed as a Bill-of-Material relationship.

When specific relationships are applicable between dissimilar objects, the relationship may be
described by singular or multiple attributes for indexing and control purposes, i.e. a named
relationship, i.e. a person object related as author to a document object.

See also OBJECT RELATIONSHIP.

Node Expansion (in the context of AVEVA NET Portal)

Clicking on the + sign in a Treeview to follow selected Association(s).to see the next tier of Nodes.

Notes

A AVEVA NET feature which allows the user to create free text, i.e. remarks, instructions,
messages, etc., in a word processor style, and associate the note with a prime object. The note can
be passed to other AVEVA NET users through e-mail if required.

See also E-MAIL and OBJECT.

Note (in the context of AVEVA NET Portal)

A AVEVA NET Portal Comment analogous to a ‘Post-it’ referring to any number of objects and which
may optionally contain a marked-up document.

© Copyright 2003 to current year.

7-38 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Object

An entity identified in and/or controlled by AVEVA NET, to achieve the goals of Object Data
Management. AVEVA NET manages two classes of objects:

• Primary Objects which include physical items, tags, virtual items and documents. Combinations
of these objects are used to define and control a object.

• Secondary Objects which include persons, organizational units, changes, modifications, waivers,
deviations, distribution lists notes, work orders, tasks and locations. The user can relate these
secondary objects in a specific logic to the primary objects, to identify or underwrite a specific
condition or relationship.

Any object is characterized by a prime identifier, attributes and, when required, relationships with
other objects.

See also CHANGE, DEVIATION, DISTRIBUTION LIST, DOCUMENT, LOCATION, MODIFICATION,

NOTE, ORGANIZATIONAL UNIT, PERSON, PHYSICAL ITEM, OBJECT DATA MANAGEMENT,
TAG, VIRTUAL ITEM and WAIVER.

Object (in the context of AVEVA NET Portal)

A AVEVA NET Portal database entity with at least one unique identifier and optionally a
classification.

Object Identification

The process to identify an object uniquely in AVEVA NET. It includes:

Allocating a prime identifier to the object.

Allocating descriptive and control attribute values to the object.

Allocating cross-references to the object, if required.

Creating horizontal relationships from the identified object to other objects to describe the
configuration of the object, if required.

Creating vertical relationships from the identified object to other identified objects to describe its
association with such objects, if required.

Creating links from the identified object to other identified objects to describe its association with
such objects, if required.

Object identification must be done in such a way that the object is uniquely identifiable, and so that
users can interpret and apply the object's associated data and relationships for a specific use.

See also ATTRIBUTE, CONFIGURATION, CROSS REFERENCE, DATA, HORIZONTAL

RELATIONSHIP, ITEM LINK, OBJECT and VERTICAL RELATIONSHIP.

Object Baseline

In the context of AVEVA NET, a object baseline for a selected root object groups together the latest
revisions of objects and documents within a defined Object Breakdown Structure.

Object Baselines can be given meaningful names, e.g. Manufacturing Data Pack for Experimental

© Copyright 2003 to current year.

7-39 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Power Supply XYZ, As-Designed Baseline, or As-Maintained Baseline.

Also see AS-BUILT CONFIGURATION, BASELINE, COMPONENT, ITEM BASELINE, OBJECT

BREAKDOWN STRUCTURE, REVISION and SERIALIZED ITEM.

Object Breakdown Structure

The hierarchical breakdown of an object into its components in a specific configuration, through
sufficient levels to show the logical make-up of the complete object group in a specific context.

The user can define various Object Breakdown Structures for the same item, depending on the
intended end use of the defined breakdown, i.e.:

A breakdown for an item that shows how it will be fabricated and assembled for production
purposes (a Production Breakdown Structure), or

A breakdown for the same item that shows how it will be maintained (a Maintenance Breakdown
Structure).

A defined Object Breakdown Structure forms the basis for AVEVA NET to assemble, control and
report all associated item data and documents for a complete object, or any part of the object.

AVEVA NET uses the Product Breakdown Structure as a default breakdown structure. This
breakdown structure represents the Product Bill of Material or parts list.

If required, the user can define and apply any other breakdown structure.

See also DOCUMENT, ITEM, ITEM-ITEM RELATIONSHIPS, OBJECT, OBJECT IDENTIFICATION,

OBJECT and VIRTUAL ITEM BREAKDOWN STRUCTURE.

Object Data

A generic term for a set of data that uniquely defines and underwrites a complete object for its
intended use. It defines what a object is in terms of human and/or machine interpretable data, with
enough detail to be able to design, manufacture, install, maintain, apply or use the object, or to
provide complete trace ability to any configuration controlled events associated with the object.

Object data is the common denominator for all business processes in the enterprise, and can be
broadly divided into the following categories:

• Configuration Data, i.e. data that describes the make-up of the item.

This data is created during the design phase of the object, and is applied during the objection,
operational and support phases of the object. It includes bills of material, assembly drawings,
circuit diagrams, etc.

• Management Control and Support Data, i.e. data that describes actions that must be performed
around the object.

This data is generated during the design phase of the object and is applied during the operational
and support phase of the object. It includes test procedures, work instructions, maintenance
manuals, training manuals, Logistic Support Analysis Records (LSAR), etc.

• Analytical Data, i.e. data which qualifies and quantifies the object's theoretical physical and
functional characteristics.

© Copyright 2003 to current year.

7-40 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

This data is generated from theoretical evaluation calculations in the design phase of the object, to
optimize object design. It includes Fault Tree Analysis (FTA), Failure Mode and Effects and
Criticality Analysis (FMECA), Reliability Analysis, Simulation, Logistic Support Analysis (LSA),
etc.

• Historical Data, i.e. data which qualifies and quantifies and records events associated with the
object which, in the future, can be useful to interpret or prove past conditions.

This data is generated during the objection, operational and support phase of the object. It includes
Test and Qualification Results, Failure Reports, Certificates of Conformance, Acceptance
Certificates, Inspection Results, etc.

Object data can be embedded in documents as well as in metadata.

See also AS-BUILT CONFIGURATION, BUILD HISTORY, CONFIGURATION, CONFIGURATION

IDENTIFICATION, DATA, DOCUMENT, ENTERPRISE, METADATA, OBJECT and OBJECT DATA
MANAGEMENT.

Object Manager (in the context of AVEVA NET Portal)

AVEVA software layered over a commercial DBMS to provide AVEVA NET Portal functionality.

Object Registration (OBR)

Object Registration Template; a unique ID optionally with a Context ID (namespace), and a longer
descriptive Name but with a mandatory Classification.

Object Relationship

The creation and maintenance of a record, which depicts an association of objects to other objects.

Relationship can be created as:

One object to another object, termed as one-to-one

One object to many objects, termed as one-to-many

Many objects to one object, termed as many-to-one.

The relationship record is created such as to allow bi-directional access, i.e. if A is related to B, then
by accessing B the relationship to A is detectable.

When objects are described in relationships to one another, the following terminology apply to the
objects:

When an object A is configured from two components B and C, B and C are child objects to parent
object A. In this example, the relationship of A to B and C is also described as a single level
relationship and is reported as a single level object list for A.

As per example above, B as child object to A, can also be a parent to child objects D and E.

When cascaded from parent A to child objects D and E, the term multi-level relationship is used
and reported as a multi-level list object list for A.

When a continuum of relationships of the same objects is defined by one-to-many relationships, it

is termed a tree-type-breakdown.

© Copyright 2003 to current year.

7-41 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

When a continuum of relationships of the same objects is defined by any combination of one-to-
many, many-to-one, or circular reference to objects, it is termed a network.

See also DOCUMENT RELATIONSHIP, LINKS.

Object Structure View

A specific way of interpreting object configuration data. Different object structure views are used for
different disciplines such as design assembly, manufacturing assembly, purchasing, documentation,
maintenance, etc.

See also OBJECT BREAKDOWN STRUCTURE.

Obsolete

Any document that is no longer 'in use' can be defined as obsolete. This implies that it is no longer
valid for use and is purely available for reference or historical purposes.

Also known as OLD or OUT-OF-DATE.

Operational Status

Used in association with a tag to identify its operational status, i.e. Planned, Operational,
Abandoned, Removed.

Offline Collaboration

Collaboration through threaded discussions (based on AVEVA NET Portal Notes).

Online Collaboration

Communication between logged-in AVEVA NET Portal users enabled by the VizStream

Comment List Control.

OPE

A COM interface over an RDBMS.

Organizational Unit

An organization associated with the activities of Object Data Management. Organizational units are
typically associated with the responsibilities of creating, changing or using data maintained by
AVEVA NET.

Organizational units can also be associated with persons in a specific role, and can be hierarchically
structured in a parent-component relationship to depict a complete definition of an enterprise.

See also COMPONENT, DATA, ENTERPRISE, OBJECT, OBJECT IDENTIFICATION, PERSON and
OBJECT DATA MANAGEMENT.

Pages

Synonym for sheets of a document.

AVEVA NET can identify the individual sheets of a document, to control the revision of each
individual sheet. When one raises the revision of an individual sheet, one must raise the revision of

© Copyright 2003 to current year.

7-42 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

the complete document.

See also DOCUMENT and REVISION.

Parts List

The parts list identifies and describes the child physical items, i.e. parts, associated with a parent
physical item, i.e. assembly.

The parts lists depict the quantity for each part in relation to the parent assembly. The parts list also,
where applicable, denotes the associated tag where it used in terms of the parent item.

The tag list is managed document in AVEVA NET. A tag list may also have a corresponding

parts list depicting the single level bill-of-material for the parent tag.

See also DOCUMENT, SINGLE LEVEL, TAG and TAG LIST.

Password (DB)

Part of the AVEVA NET Portal Connection string.

Pay per Use Licensing

A new licensing model from AVEVA based on software usage; another name for Token based
Licensing.

pdf File

A document format from Adobe with limited support in AVEVA NET Portal (picking is supported but
not highlighting).

Permissible Association

A user-specified association between AVEVA NET Portal Classes defining an association that is
permitted between AVEVA NET Portal Objects of these two classes.

Permissions

The assignment of permissions in AVEVA NET which authorizes users to use the various functions.
This includes access to transactions and authorizing users to add, change, delete and/or view data
maintained by AVEVA NET.

See also ACCESS LEVEL, DATA, SYSTEM ADMINISTRATOR USER and USER GROUP.

Person

An identifiably human object associated with the activities of creating, changing or using object
master records or object content but without any direct access or privileges to the system.

See also DATA, OBJECT, OBJECT IDENTIFICATION, ORGANIZATIONAL UNIT, OBJECT DATA
MANAGEMENT and WORKGROUPS.

Physical Attributes

Quantitative and qualitative expressions of item features, such as composition, dimensions, finishes,
form, fit, and their respective tolerances.

© Copyright 2003 to current year.

7-43 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

See also FIT, FORM AND FUNCTION.

Physical Item

An item which can be identified as a single stand-alone entity with specific physical and functional
characteristics. It can be procured, stored, distributed, fabricated, assembled, maintained, applied,
etc. A physical item can be broken down into other physical items (components) in accordance with
a specific configuration.

Items such as plant equipment, support equipment, weapons, aircraft, ships, tools, computers,
vehicles, and their components such as mechanical, electrical, electronic, hydraulic and pneumatic
parts, are classified as physical items.

Physical item identification may also be extended to its application in a specific location fulfilling an
identified function by means of the tag object.

The term Hardware can also be used as an alternative to Physical Item. Software items (other than
document software files) and firmware are handled by AVEVA NET as physical items.

See also CONFIGURATION, DOCUMENT, EQUIVALENT, FIRMWARE, ITEM, LOCATION,

SOFTWARE, TAG and VIRTUAL ITEM.

Physical Item Qty Per

A concept associated with Tags. Denotes the number (quantity) of physical items that are required
by the tag. The typical quantity is one.

See also TAG.

plt File

A PDMS PLOT file – the format used for PDMS ISOs and DRAFT GA drawings.

Plug-in (in the context of AVEVA NET Portal)

Software to which the AVEVA NET Portal Import Server delegates the processing of a particular file
format.

Portal (in the context of AVEVA NET Portal)

An earlier name for the AVEVA NET Portal Dashboard (the name is still visible in the installed
software).

Preferred Physical Item

A concept associated with the Tag object.

It refers to the physical item designated to fulfil the function required by the identified tag

A range of preferred physical items maybe specified for use by the tag. AVEVA NET requires this
range of physical items to be prioritized.

Prime Identifier

A unique number consisting of alphanumeric characters allocated to an object, to uniquely and

unambiguously identify the object as a singular entity. A prime identifier cannot be used more than

© Copyright 2003 to current year.

7-44 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

once for an object of the same type.

AVEVA NET is insensitive to the format of prime identifiers, and does not rely on the intelligence
embedded in the prime identifiers for its operational logic.

A typical example of a prime identifier is the item number allocated to an item, or the identification
number of a person.

See also OBJECT and OBJECT IDENTIFICATION.

Process
A defined set of actions taken by human and/or machine resources in response to a specific

input, to achieve a required output.

The input for a process can be a defined command, data, items, or conditions, and/or combinations
of these. The required outputs for a process are quantified and qualified parameters by standards,
specifications, next process interface and/or expectations, or combinations of these.

A process is also associated with the terms throughput, efficiency, reliability, status, etc.

A defined input, process and output is referred to as a function. Processes and functions are
identified and managed by AVEVA NET as Virtual Items.

See also FUNCTION, FUNCTIONAL CHARACTERISTICS and VIRTUAL ITEM.

Product Data Management (PDM)

Technology and methodology used within an enterprise to identify, organize, access, maintain and
control data related to its products. Product data management is applied over the complete life cycle
of the object, and has the following objectives:

To identify and maintain the make-up (configuration) of objects.

To identify and maintain all object data and documents related to the object, and/or manage the
creation of object data.

To manage orderly change to a object in terms of its configuration and associated object data.

To provide optimum and controlled access to object data by business processes.

Product data management consists of three disciplines:

Configuration Management which:

Identifies the item configuration and associated item data,

Manages controlled and orderly change to item configuration and item data,

Reports on the configuration and data status of the item, and

Verifies integrity of data and documents through audit.

Document Management which manages associated processes and infrastructure, to provide

secure and controlled receipt, storage, access, maintenance and distribution/ promulgation of all
data sets associated with the object.

© Copyright 2003 to current year.

7-45 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Work Management which manages the work that persons and organizational units perform when
creating, maintaining and changing object configurations and associated object data.

See also CHANGE, CONFIGURATION, CONFIGURATION CONTROL, CONFIGURATION

IDENTIFICATION, CONFIGURATION MANAGEMENT, CONFIGURATION STATUS ACCOUNTING,
DOCUMENT, DOCUMENT MANAGEMENT, ENTERPRISE, ORGANIZATIONAL UNIT, PERSON,
OBJECT, OBJECT DATA and WORK MANAGEMENT.

Product Information Management (PIM)

The integrated management of all data related to a object in the context of the enterprise. Within the
enterprise, different pieces of object data are created and maintained by a variety of tools, and are
stored in files and databases which reside on multiple electronic media.

Product information management integrates the data creation, requirements and usage of multiple
legacy systems used to design, analyse, manufacture and support a object throughout its life cycle.

See also ENTERPRISE, LEGACY SYSTEM, OBJECT DATA, OBJECT DATA MANAGEMENT and
OBJECT LIFE CYCLE.

Program Management

The planning, directing and controlling of resources to achieve specific program or project objectives.
Program management tracks and reports factors such as technical, cost and schedule performance
against set budgets.

Work associated with a program is generally defined and executed within the framework of a work
breakdown structure which identifies the associated tasks and activities in a logical breakdown.

It includes the identification of required resources and the allocation, authorization and control of
work performed by these resources within set budgets.

Project Management and Object Management are synonyms for Program Management.

See also WORK BREAKDOWN STRUCTURE and WORK MANAGEMENT.

Project

This object serves the purpose to give "ownership" to objects as well as to provide additional "group"
security options and can be related to most objects in the system.

See also GROUPS, PERMISSIONS.

Project Context

A string included as a place-holder in AVEVA NET Portal import files that is replaced by the ‘Top
Object’ ID during processing by the AVEVA NET Portal Import Server.

Project Management

See PROGRAM MANAGEMENT.

Purge (DB)

Reducing the size of a database by eliminating all the archived entities (those marked as deleted).

© Copyright 2003 to current year.

7-46 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Quality

The degree to which a system, component or process meets specified requirements or customer
expectations.

See also QUALITY ASSURANCE, TOTAL QUALITY MANAGEMENT.

Quality Assurance (QA)

A planned and systematic approach to make sure that a object conforms to established technical
requirements.
See also QUALITY ASSURANCE, TOTAL QUALITY MANAGEMENT.
Queue

A list of activities/work steps that were submitted for execution to a group people or resources.

RealityWave

The suppliers of VizStream.

Records Management (RM)

Redline

To annotate a graphic or text object by placing comments either on the original or on overlays with
the original.

See also ANNOTATE.

Reference Counting

Used in AVEVA NET Portal to delete an object or association when the number of template
references to it drops to zero.

Relational Database Management System (RDBMS)

Database management systems that maintain data records and indices in tables. The user can
create and maintain relationships across and among the data and tables.

See also DATABASE MANAGEMENT SYSTEM.

Reference Data Library (RDL)

User-definable hierarchy of Classes, Attributes, Associations and Permissible Associations; known

as the Class Library in AVEVA NET Portal.
Released
The action taken by a specific user to make a document available 'for use' in support of the intended
business process or item.

This status signals the start for complete control (freezing of metadata) and often heralds the start of
Records Management activities.

Also known as ISSUED.

Repository

© Copyright 2003 to current year.

7-47 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

AVEVA NET's computerized data storage area. System rules and processes control storage of data
in AVEVA NET repositories.

See also VAULT.

Retroview

Third-part software used for displaying photo-grammetry images in AVEVA NET Portal.

Review

A process in which one or more persons verify defined and/or changed documents and/or data to
determine whether the definition and/or changes have been correctly performed.

See also DOCUMENT APPROVAL and ITEM APPROVAL.

Review2XGL

AVEVA NET Portal Utility for converting PDMS Review format files to VizStream format.

Review-OE

AVEVA software component for rendering 3D images now replaced in AVEVA NET Portal by
VizStream.

Revision

The authorized and documented level of a document.

Revision levels are defined and updated according to configuration management change control rules.
The number of revisions on a document indicates how many changes have been done to the
document to correct its data.

The document number of a document plus its revision number forms the unique prime identifier for
that document.

See also CHANGE, CONFIGURATION CONTROL, DATA, DOCUMENT and PRIME IDENTIFIER.

Role (in the context of User)

The Role that can be created and assigned to a User by a User who has the Administrator Role; the
User Role controls the appearance of the Tree-view.

Root Node (in the context of Dashboard)

The top node in the Treeview, a Menuset, usually linked to a ‘Top Object’ of class Project or Plant.

rvm File

A PDMS Review format file.

rvz File

A Compressed PDMS Review format file.

Scalable Vector Graphics (SVG)

© Copyright 2003 to current year.

7-48 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Scalability

Issues related to the amount of data to be handled.

Sectionalisation

An earlier name for AVEVA NET Portal Sets.

Security

The rules that restrict access to, and manipulation of, a document master record and/or the
document content.

Security encompasses the terms authentication and authorization where authentication refers to
determining the identity of the user attempting the access, and authorization refers to determining
the set of privileges available to the user, i.e. permissions.

See also DOCUMENT PERMISSIONS, DOCUMENT PERMISSSIONS TEMPLATE, DOCUMENT

SECUTITY TEMPLATE.

Serial Number

An identifier which, together with an item prime identifier (part number/item number), identifies an
individual physical item where a quantity of the same item has been processed as one group (i.e.
manufactured).

A serial number is allocated to an item for maintaining records against the individual item, and can
include:

A object baseline,

Build history,

Waivers, deviations and modifications, and.

The as-built configuration record for a complete main equipment.

A serialized item can have the following characteristics:

It is a removable and maintainable item.

It can be main equipment.

It is an entity with functional and physical characteristics which must be measured to determine
and record suitability for use.

See also AS-BUILT CONFIGURATION, BATCH NUMBER, BUILD HISTORY, DEVIATION,

FUNCTIONAL CHARACTERISTICS, MAIN EQUIPMENT, MODIFICATION, PHYSICAL
CHARACTERISTICS, PHYSICAL ITEM, OBJECT BASELINE, SERIALIZED ITEM, SERIAL NUMBER
STRUCTURE and WAIVER.

Serial Number Structure

A user-definable structure which denotes the hierarchical breakdown of serialized items in a main
equipment, in a parent-component relationship. The serial number structure forms the backbone for
deriving the as-built configuration of main equipment.

© Copyright 2003 to current year.

7-49 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

See also AS-BUILT CONFIGURATION, COMPONENT, MAIN EQUIPMENT, PARENT and

SERIALIZED ITEM.

Serialized Item

A specific single physical item identifiable through the combination of an item number/serial number
combination.

A serialized item is the key identifier to which:

A object baseline is allocated,

Build history is allocated,

Waivers, deviations and modifications are associated, and

The build state record for a complete main equipment is maintained.

Items identified in batches are managed in the same way as serialized items by AVEVA NET.

See also AS-BUILT CONFIGURATION, BATCH NUMBER, BUILD HISTORY, DEVIATION, MAIN
EQUIPMENT, MODIFICATION, PHYSICAL ITEM, OBJECT BASELINE, SERIAL NUMBER, SERIAL
NUMBER STRUCTURE and WAIVER.

Set (in the context of AVEVA NET Portal)

User defined container of AVEVA NET Portal objects that will survive an update run.

Sheets

See PAGES.

Shoebox

Nickname for a Micro server

Simple ID

The ID string for a AVEVA NET Portal object without a Context – if not unique this may refer to more
than one object.

Simple Object Access Protocol (SOAP)

Single Level

The term Single Level implies any parent object, at any level of the hierarchy, seen with its direct
(one level lower) associated child objects (components).

Parts Lists and Tag Lists are examples of single level lists.

See also COMPONENT, OBJECT, PARENT, PARTS LIST and TAG LIST.

Site Acceptance Test (SAT)

Site Acceptance Test that takes place at the customer’s premises.

Snapshot

© Copyright 2003 to current year.

7-50 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

See BASELINE.

Snapshot Update

Complete regeneration of a AVEVA NET Portal Database from a Staging Area; the update

strategy used by AVEVA NET Portal Navigator (c.f. Incremental Update).

Software

A combination of associated computer instructions and computer data definitions which enables
computer hardware to perform a specific task.

• AVEVA NET manages software in the following way:

• Document software (files created by a word processor or CAD) as documents.

• The executable software which is loaded into a programmable device for machine interpretation (i.e.
firmware) as a physical item.

• The executable software for an application as a physical item.

See also DOCUMENT, FIRMWARE, ITEM and PHYSICAL ITEM.

Spicer Tools

Utilities for converting a range of document formats, including MS Office, into VizStream format. (Not
currently available for use with AVEVA NET Portal)

SQL Server

Microsoft’s relational database management system.

SRP

The AVEVA NET Portal test Staging Area based on the PDMS SAMPLE database.

Staging Area

Hierarchy of folders and files defining a complete set of project information for importing into AVEVA
NET Portal.

Standard Generalized Markup Language (SGML)

A methodology for defining and marking up the content of electronic documents. It provides
structured documents to a specific standard.

Status

The status defines the following groups of information to be used to describe or control documents:

Life Cycle:

Planned status (document does not yet exist),

Draft status,

© Copyright 2003 to current year.

7-51 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Validated status,

Released (with effectivity) status,

Under Revision status,

Disposal (includes, obsolete, superseded, archived and destroyed) status.

Revision:

Latest (current) status,

Historic status,

Obsolete status,

Control:

Subject to Change Control status,

Records' status,

Change Pending status,

Released for Change (approved ECN from Change Process) status,

Draft/Latest revision status,

Checked out or in status,

Superseded by' status,

Archived status,

Destroyed (for Records) status.

See also LIFECYCLE; VALIDATE; RELEASED; REVISION CONTROL.

Structured Query Language (SQL)

The ANSI standard query language for relational database systems.

See also DATABASE MANAGEMENT SYSTEM.

Structured Vector Graphics (SVG) File

Structured Vector Graphics - an XML format used by AVEVA NET Portal for displaying schematics
documents.

Structured Vector Graphics (SVG) Viewer

Adobe software used in AVEVA NET Portal for displaying svg files.

Superseded

Any document that is set aside and is 'replaced by' another is regarded as superseded. This implies
that a document has been replaced by a newly referenced document and any reference to the

© Copyright 2003 to current year.

7-52 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

superseded document must be replaced with the superseding one.

Also known as REPLACEMENT.

Symmetrical Association (in the context of AVEVA NET Portal)

An association which reads the same when navigated in either direction.

System Administrator

The person who sets up, manages and customizes AVEVA NET to meet the needs of the
enterprise. It includes the identification of users or user groups, and the management of access and
permissions to data.

See also DATA, ENTERPRISE, OBJECT DATA MANAGEMENT, USER and USER GROUP
Tag
The tag object represents as a single and unique entity the combination of a defined physical item
performing a specified function in a specific location.

In order to preserve the uniqueness of a tag, it is always identified in the context of an entity to which
the tag is associated, i.e. a plant, or a unit, or assembly. In AVEVA NET this entity is referred to a
the primary physical item.

AVEVA NET manages all three these dimension in consideration to the tag, namely what the tag
should do (function represented by a virtual item), what physical item should perform the function
(preferred physical item) and where its should be performed (Location)

AVEVA NET also provides the ability to track history relative to the tag in terms of physical items
fitted. Such tracking maybe accomplished to serial number.

Depending on the user environment, the tag object is also known as a component, plant item, asset,
or as tag.

A tag is a uniquely identified position in a process network performing a specific function through a
specific item at a point in time. A tag management system should thus be able to manage both what
can be used in a specific tag position and what is currently fitted in the tag position.

See also PHYSICAL ITEM, PREFERRED PHYSICAL ITEM, LOCATION, SERIAL ITEM and
VIRTUAL ITEM.

Tag State

Used in association with a tag to identify the status of its descriptive data, i.e. under change, or
latest approved

Tag List

The tag list identifies and describes the child tags associated with a parent tag.

The tag list is managed document in AVEVA NET. A tag list may also have a corresponding

parts list depicting the single level bill-of-material for the parent tag.

See also DOCUMENT, PARTS LIST, SINGLE LEVEL and TAG

© Copyright 2003 to current year.

7-53 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Tag Prototypes

AVEVA NET provides the capability to copy a user identified set of data and documents associated
with a tag to a workspace for the purpose of change without affecting the existing tag and its
associated data and documents.

Once the associated document and data changes have been implemented and approved it may then
be rolled back to update the associated tag.

This capability is typically applied where design work is required on an existing plant item

without influencing the existing deployed item and its data and documents.

Tag (XML)

The <name> of an XML element in angle brackets.

Task

A small portion of work to be performed within a work order. Work is normally broken down into
smaller portions to manage each portion more effectively.

Each task is allocated to a responsible person who has to perform the work within a specific time
frame or schedule and within an allocated budget.

See also SCHEDULE and WORK ORDER.

Task Delegation

The process whereby the responsible person for a specific task authorizes someone else to
complete the task or part of a task on behalf of him. The original responsible person retains the
responsibility to make sure that the task has been fully completed before signing of the task.

Technical Data Management

A synonym for Object Data Management.

See also DATA, DOCUMENT, DOCUMENT MANAGEMENT, OBJECT DATA and OBJECT

DATA MANAGEMENT.

Test Scenario

A document describing how to set up and run a test.

Threaded Discussion (in the context of AVEVA NET Portal)

A succession of AVEVA NET Portal Notes with the same ID but with different revision numbers.

Timeout (IIS)

See IIS TIMEOUT

Token Based Licensing (TBL)

A relatively new licensing model introduced by AVEVA based on logging software usage in units of
time, analysed later for billing purposes.

© Copyright 2003 to current year.

7-54 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Top Object

The AVEVA NET Portal object, usually of Class ‘Plant’ or ‘Project’ providing the Context for
information within a Staging Area.

Total Quality Management (TQM)

An approach to quality, including object and process quality, but extending to virtually anything done
by an organization for external and internal customers (what marketing does for manufacturing, for
example). Its aim is to encourage an enterprise-wide emphasis on quality and doing the job right the
first time.

See also ENTERPRISE, PROCESS, OBJECT and QUALITY ASSURANCE.

Transaction

See also.

Transmittal

See DOCUMENT REQUISITION.

Transmission Control Protocol/ Internet Protocol (TCP/IP)

A communication standard for connecting computing systems. It includes interactive, file and mail
interchange standards.

See also CLIENT/SERVER, LOCAL AREA NETWORK and WIDE AREA NETWORK.

Tree-view

AVEVA NET Portal component for navigating a hierarchical view of the network of

information in the AVEVA NET Portal Database.

Type Classification

The assignment of a single or hierarchical set of attributes to a document to allocate

secondary identifying data which can be applied for:

• Accessing documents with a specified classification, or

• Grouping together and reporting a range of documents with a similar or exact

classification, as specified.

Also known as TYPE or CLASS.

Typical

Earlier name for a AVEVA NET Portal Attribute Template.

Unclassified Object

A AVEVA NET Portal object without a classification – treated as if it were of Class UNKNOWN.

© Copyright 2003 to current year.

7-55 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Underwrite

Used in the context of configuration identification where data and documents are created, recorded,
maintained and controlled to fully identify an item.

See also CONFIGURATION IDENTIFICATION, DATA and DOCUMENT.

Unicode

Internal character representation used by AVEVA NET Portal that is capable of representing most
languages.

Unit of Measure (UOM)

Prior to Units of Measure being introduced into AVEVA NET Portal attributes of an object consisted
of 2 parts - a name (of the attribute) and a value (of the attribute for this object.)

These attributes are implemented as Characteristics in the Portal (This detail is not apparent in the
dashboard, but can be seen using the Admin Tool). As an example of this type of attribute.

Paint Colour (attribute name) = red (attribute value)

With the introduction of UOMs to AVEVA NET Portal an additional implementation of attributes is
introduced - the Property (as opposed to Characteristic.) A Property consists of 3 parts - a name, a
value and a UOM for example:

Weight (attribute name) = 45 (attribute value) kg (attribute value's UOM).

Universal Naming Convention (UNC)

Universal Naming Convention – a name for a file that can be used in place of a URL provided the
machine on which it resides is on the same network.

Universal Resource Locator (URL)

Universal Resource Locator; the internet address of a file.

UNKNOWN Class

The pseudo AVEVA NET Portal class of unclassified Objects that can be used in a ‘Find’ query for
unclassified Objects.

Upper Ontology

The fixed part of the AVEVA NET Portal Class Library, built by the AVEVA NET Portal
Bootstrap.exe, from which all user-defined Classes must be sub classed.

User

An identifiable human object, which has access to the system by virtue of rights and permissions,
allocated for the purpose of creating, maintaining and/or use of object master records or object
content.

The system administrator allocates rights and permissions to a user.

See also ACCESS LEVEL, DATA, PERMISSIONS, PERSON, SYSTEM ADMINISTRATOR, USER

© Copyright 2003 to current year.

7-56 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

GROUP and VIEW.

User-Defined Attribute (UDA) (PDMS)

User-Defined Attribute – data handled in AVEVA NET Portal as name-value pairs in an XML Dataset
string.

User Group

A group of users who have the same access to AVEVA NET. These users can create, maintain or
view data by virtue of the rights allocated to the user group.

The system administrator can allocate AVEVA NET system and data access rights and permissions
to a user group.

See also GROUPS, ACCESS LEVEL, DATA, PERMISSIONS, PERSON, SYSTEM

ADMINISTRATOR, USER and VIEW.

Validate

The end action after the review process taken by a 'Creator' and 'Designated User' to confirm that the
contents of a document are 100% accurate.

Also known as APPROVAL or AUTHORIZATION.

Version

An identified and documented variation of an approved and controlled physical item.

Item versions enable the user to identify variations of a basic item configuration. Identification of a
new version of an item configuration does not affect the baselines of current existing versions of the
same basic item.

Versions can be applied to both hardware and software. The allocated part number and the version
form the unique prime identifier for the physical item.

See also BASELINE, CONFIGURATION, CONFIGURATION ITEM, HARDWARE, PHYSICAL ITEM,

PRIME IDENTIFIER and SOFTWARE.

Vertical Relationship

A term used within the context of AVEVA NET to depict the relation between a virtual item and a
physical item.

For example, the virtual item Hydraulic System may have references to physical items Pump XYZ
and Pipe ABC.

See also HORIZONTAL RELATIONSHIP, ITEM-ITEM RELATIONSHIPS, PHYSICAL ITEM and

VIRTUAL ITEM.

View

To access data and/or graphical objects from a workstation.

Graphical objects are generally presented in raster format. View applications allow the user to zoom,
pan and otherwise modify the display of an object.

© Copyright 2003 to current year.

7-57 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

See also DATA, GRAPHICAL USER INTERFACE, USER and WORKSTATION.

Virtual Item

An item of a functional nature which, as an integrated or single entity, cannot be identified as stand-
alone and tangible. It cannot perform or achieve an end function without associated physical items
and/or human involvement.

Alternatively, a virtual item is any other item that does not conform to the definition of a physical
item. A virtual item has functional characteristics which can only be achieved through physical items
and/or interaction with persons.

The association of a virtual item with a physical item is created through a vertical relationship. A
virtual item is associated with a person through the allocation of responsibilities (persons or
organizational units) to the virtual item.

Typical examples of virtual items are a hydraulic system or manufacturing process. Functions and
processes are typically identified as virtual items.

See also FUNCTION, FUNCTIONAL CHARACTERISTICS, HORIZONTAL RELATIONSHIP, ITEM,

ITEM-ITEM RELATIONSHIPS, ORGANIZATIONAL UNIT, PERSON, PHYSICAL ITEM, PROCESS,
VIRTUAL ITEM BREAKDOWN STRUCTURE and VERTICAL RELATIONSHIP.

Virtual Item Breakdown Structure

As with physical items, a virtual item can also be broken down into component virtual items by
creating horizontal relationships between virtual items, or between the parent virtual item and its
components, to define a complete process or functional breakdown. This breakdown is called a
Virtual Item Breakdown Structure. A virtual item breakdown structure can only be defined in the
context of a Virtual Item Group.

See also COMPONENT, HORIZONTAL RELATIONSHIP, ITEM-ITEM RELATIONSHIPS, PARENT,

PHYSICAL ITEM, VIRTUAL ITEM and VIRTUAL ITEM GROUP.

Virtual Item Group

A virtual item with its end-function can only be identified in the context of an overall enditem, e.g.:

The Hydraulic System of Aircraft XYZ, or

The Supplier Order Placement Process of Company ABC.

The context (or end-item) within which a virtual item's function is identified, is termed the Virtual Item
Group. In the examples above, Aircraft XYZ and Company ABC are Virtual Item Groups.

The term Hat is also used as an alternative to Virtual Item Group.

See also VIRTUAL ITEM and VIRTUAL ITEM BREAKDOWN STRUCTURE.

VizStream

Third Party Software from RealityWave for streaming data, especially 3D data, to a AVEVA NET
Portal Dashboard.

VizStreamComment

© Copyright 2003 to current year.

7-58 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

The AVEVA NET Portal object supporting Online Collaboration Sessions – displayed in the
Comment List Control.

VBScript

One of the languages used on the client side.

vnet File

File with a .vnet suffix, paired with another file of the same name, supplying metadata as an XML
string (e.g. Class name, Document Name).

Waiver

A written authorization to accept a physical item which, during manufacture, or after inspection, is
found to depart from specified requirements, but is considered suitable for use as is or after repair by
an approved method.

The customer typically allots waivers to the contractor to avoid losses due to scrap, possible rework
and schedule slippage.

A waiver event is further characterized by the following:

It is directly associated with a serialized item.

It has a specified effectivity.

A waiver does not warrant change to a baseline.

A waiver record will be maintained by AVEVA NET as part of the item's build history.

See also AS-BUILT CONFIGURATION, BASELINE, BUILD HISTORY, CHANGE, CONFIGURATION

STATUS ACCOUNTING, EFFECTIVITY, ITEM BASELINE, PHYSICAL ITEM and SERIALIZED ITEM.

Warehouse Manager

Not currently implemented in AVEVA NET Portal.

Web-enabled

Software, of which the AVEVA NET Portal Dashboard is an example, which is used through a
Browser such as Internet Explorer.

Wide Area Network (WAN)

A communication network that spans a large, geographically distributed, multi-site environment.

WANs typically use protocols that provide higher transmission rates than LANs.

See also LOCAL AREA NETWORK.

Wildcards

Used in DB queries; see % and _

Windows 2003 Server

A recent version of the Windows OS which will require some re-implementation of AVEVA NET

© Copyright 2003 to current year.

7-59 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

Portal.

Windows Authentication

The mechanism on which AVEVA NET Portal depends to provide secure access to the AVEVA NET
Portal Database.

Windows Sharepoint Services

The Microsoft software underpinning the AVEVA NET Portal Object Summary and Tag Summary
features.

Wireless Application Protocol (WAP)

Work Authorization (WA)

Work Breakdown Structure (WBS)

A WBS is a mechanism for breaking work (generally related to a specific program) into smaller
elements (i.e. tasks and activities), which can be used for assigning resources, budgets, schedules,
etc.

The WBS provides a framework for controlling programs.

See also PROGRAM MANAGEMENT and WORK MANAGEMENT.

Working Data

Data that has been imported into an area of the AVEVA NET Portal database but not yet Issued for
general use.

Work Flow

Workflow is the tasks, procedural steps, organizations or people involved, required input and output
information, and tools needed for each step in a business process. A workflow approach to analysing
and managing a business process can be combined with an object oriented approach, which tends
to focus on documents, data, and databases. In general, however, workflow management focuses on
processes rather than documents.

Workhub

Another name for the AVEVA NET Portal Server.

Work Management (WM)

Assigning resources to identified work, and authorizing, monitoring, controlling and reporting the
performing of this work within defined schedules, cost and technical requirements.

In the context of AVEVA NET, work management is mainly concerned with:

The creation/acquisition of object data (Configuration Identification),

The implementation of changes to object data (Configuration Control),

The verification of object data integrity (Configuration Audit).

See also CONFIGURATION CONTROL, CONFIGURATION IDENTIFICATION, CONFIGURATION

© Copyright 2003 to current year.

7-60 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

MANAGEMENT, OBJECT DATA, OBJECT DATA MANAGEMENT, PROGRAM MANAGEMENT and

WORK BREAKDOWN STRUCTURE.

Work Order (WO)

An authorized legal document between a project manager and another person authorizing the person
to perform a specific task, within a specific budget and schedule.

A work order will result in the supply of finished task. A work order, when placed on objection to
manufacture goods, will result in the supply of goods.

See also SUPPLY.

Work-pack

See also

Workplace

The name for the standard AVEVA NET interface that is provided with the product. It includes several
views (or navigation tabs) of the system including General Navigator, Enterprise Navigator, Search
Navigator and Revision Control Navigator.

Work Task

See TASK.

Workgroup

Any group of persons working towards a common goal as a team. An enterprise will typically have a
number of workgroups involved in a object development program.

See also ENTERPRISE, PERSON and PROGRAM MANAGEMENT.

Workstation

A system consisting of a computer, a set of applications or tools, and integrated interactive graphics
capabilities, primarily used by one person.

A workstation typically provides the interface between the user and a database.

XGL File

XML format for GL graphics - the format read by VizStream.

Extended Mark-up Language (XML) Spy

Popular utility used for inspecting and editing XML files.

XMpLant

Software licensed for use with AVEVA NET Portal for mapping Process data from one format to
another.

XSLT

Used to convert XML from one format to another using a specification itself written in XML.

© Copyright 2003 to current year.

7-61 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 AVEVA NET Fundamentals Guide
Glossary of Terms

ZGL File

A compressed xgl file – the format used by VizStream.

© Copyright 2003 to current year.

7-62 4.7.7
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.