Aveva Net Fundamentals Guide

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-1 2 AVEVA............................................................................................................ NET Architecture Key Features ..................................................................................................................................... 2-1 AVEVA ..................................................................................................................................... NET Core Components 2-1

............................................................................................................ 3-1 3 Enterprise Content and Configuration Management 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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

i

4.7.7

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-1 4 AVEVA............................................................................................................ NET Portal Overview 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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

ii

4.7.7

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-1 6 Associative Object and XML Schema 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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

iii

4.7.7

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-1 7 Glossary of Terms Definitions ..................................................................................................................................... 7-1

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

iv

4.7.7

AVEVA NET Fundamentals Guide

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

v

4.7.7

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 Configuration Management Principles AVEVA NET Portal Overview

Describes the principles of Enterprise Content Management in context of AVEVA NET.

SVG Specification

Describes the use of the SVG specification in context of AVEVA NET.

Associative Object and XML Schema Glossary of Terms

Describes AVEVA NET Portal Associative Object and XML Schema A glossary of terms used in this guide.

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

On overview of AVEVA NET Portal and its capabilities.

1-1

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

2-1

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

2-2

4.7.7

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

Configuration Identification

The configuration of the item/product/assets I work with -what 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?

Configuration Status Accounting Configuration Verification (Audit)

3.1

What changes have been made to the item(s)? What records are maintained? Does the item conform to the stated needs and is it reflected in the supporting data (documentation)?

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

3-1

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

3-2

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

3-3

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

3-4

4.7.7

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 Configuration Identification

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

Question The configuration of the product/process I work with - what does it consist of, how does it interface with other systems and what data underwrites them?

3-5

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

3-6

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

3-7

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

3-8

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

3-9

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

3-10

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

3-11

4.7.7

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 applicationproduct-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 inhouse 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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

4-1

4.7.7

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 shortterm 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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

4-2

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

4-3

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

4-4

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

4-5

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

4-6

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

4-7

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

4-8

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

4-9

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

4-10

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

4-11

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

4-12

4.7.7

AVEVA NET Fundamentals Guide AVEVA NET Portal Overview

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

4-13

4.7.7

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

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

5-1

4.7.7

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"> <desc> There should be no script or built in behaviour within the SVG document. This includes the use of the 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 element and styled using a style attribute on the 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 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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

5-2

4.7.7

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 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>90GMM10CL002 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 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 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 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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

5-3

4.7.7

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: <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"> <desc>An example SVG document for VNET <metadata> one <metadata> two <metadata> four <metadata> three <metadata> five <metadata> six <ellipse cx="50" cy="80" rx="20" ry="10" style="fill:lemonchiffon; stroke-width:1"/>

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

5-4

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

5-5

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-1

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-2

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-3

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-4

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-5

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-6

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-7

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-8

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-9

4.7.7

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 subclassed 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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-10

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-11

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-12

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-13

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-14

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-15

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-16

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-17

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-18

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-19

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-20

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-21

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-22

4.7.7

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. AVEVA Solutions Limited and its subsidiaries. All rights reserved.

6-23

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-24

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-25

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-26

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-27

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-28

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-29

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-30

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-31

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-32

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-33

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-34

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-35

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-36

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-37

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-38

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-39

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-40

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-41

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-42

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-43

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

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

6-44

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema

6.20 AVEVA NET Portal XML Schema Reference Object ID (Unclassified)

Object with Essential Classification

Object ID with Access Control

Descriptive Name

Context

Nested Context



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

6-45

4.7.7

AVEVA NET Fundamentals Guide Associative Object and XML Schema Revision (of Document)

Association