Administration Elements

One of the main functions of AVEVA Administration is creating and managing the AVEVA’s base product administration elements. The fundamental elements are Teams, Users, DBs (databases) and MDBs (multiple databases).

DBs and Teams are closely related: a DB must be owned by a Team, and only the Users who are members of the owning Team have write access to the DB.

MDBs are collections of DBs. When the user enters an AVEVA base products constructor module (Model, Spool, Draft or Isodraft the user must specify an MDB, and this defines which DBs the user will be able to access. The System Administrator must set up MDBs in each project so that users can access all the DBs they require.

Users are defined by an identifier and password, which allows them to enter the AVEVA base product. Users are normally members of Teams, which gives them write access to DBs owned by the Team, but a user who only needs read access does not have to be a member of a Team.

In addition, the user can optionally create other elements which can help administer a project, and gives the user more flexibility in controlling work flow and access rights:

Extract Databases, including Working Extracts, allow users to Claim elements from a primary DB, then Issue work back to the primary DB when they are satisfied with the changes they have made. Variant databases allow users to try out different designs: the best can then be merged back into the primary database.

Stamps are used to mark database sessions at a specific time and date, enabling key dates to be more easily identified.

Roles and Scopes are combined into Access Control Rights (ACRs), which give more precise control over users' access to databases.

DB Sets are collections of DBs which can be handled as a single entity. For example, the user could make a DB set containing several catalogue databases, which could then be added to MDBs all together.

Disciplines represent different engineering disciplines. The attributes of tagged items will be divided between multiple disciplines, each group of discipline attributes to be editable by users within the discipline in question.

Within a discipline, items are promoted through the status of the define lifecycle, e.g. typically from Working to Approval and finally to Issued. These status are Maturity level elements.

Baselines are views of a project consisting of all data from all disciplines saved at a particular state. Disciplines can continue to change data and create new revisions of data without changing the project views saved to baselines.