Multi-Disciplinary Project Data

Multi-Disciplinary Project Data provides the administrator with Controlled Object Revisioning (COR) functionality.

COR is used to control when and if users are alerted to changes to objects made by disciplines other than their own. When such changes are made, and the objects are released via status control, a notification is sent to any users that have subscribed to that object. Users may then decide if and when to adopt the change for their own discipline.

For example, in a typical Datasheet a number of attributes from different disciplines provide the user with an overview of an item. The user will need to modify attributes within their discipline, and also want to see attributes from other disciplines. When attributes from the other disciplines change, the user will want to control when they see those changes. COR enables this to be implemented by deploying an extract hierarchy that allows users to choose when to pick up status changes from other disciplines.

An extract hierarchy is used to support an object lifecycle (for example, Issued > Approval > Working) and release mechanism, and in addition provide a number of consumer extracts. These consumer extracts enable users from other disciplines to pull changes into their own extract hierarchy and view.

Within a discipline, items are promoted through the status of the define lifecycle, e.g. typically from Working to Approval and finally to Issued. Upon reaching the Issued status, the system sends a notification to users that have subscribed to the object inform them that changes have been and are available to them. The users can optionally choose whether or not to adopt the change.

Inter-Discipline Project Setup

It is the responsibility of Project Administrators to set up COR for projects, ensuring that the required extract hierarchies, Teams and Multiple Databases (MDBs) are available. An Inter-Discipline Project Setup feature is provided to help Administrators do this. The feature partially automates the setting up of the required teams, databases, MDBs etc in accordance with user-defined parameters.

Other objects that are required to be setup for COR are Disciplines and Maturity levels.

Disciplines are the engineering disciplines (Piping, Electrical, etc) required for Inter-Discipline Project set-up. Maturity levels determine the status approval workflow, or items, e.g. Issued > Approval > Working. When the automation process is run an extract hierarchy will be created for each discipline, with consumer extracts also generated for each discipline extract hierarchy other than itself.

Global Inter-Discipline Project Setup

Global Interdisciplinary Project Setup is supported: setup can be configured for a single location, either the Hub or a Satellite.

For the Hub, project automation can be undertaken as a single process; however for Satellites the process needs to be divided into Hub operations and Satellite operations.

Teams, databases and extract hierarchies must be created at the Hub. These databases and extracts are then allocated to the appropriate Satellite. The Satellite automation process generates MDBs to be used at that location.

Interdisciplinary Project Setup can be run without databases being allocated to the Satellite, but the global DB must be propagated before the process can generate its own MDBs.

The workflow for Interdisciplinary Project Setup for a Satellite is:

At the Hub:

• Create Disciplines.

• Create Maturities.

• Create Locations.

• Run Interdisciplinary Project Setup at the Hub.

• The system creates Teams, Databases and Extracts.

• If the Satellite is initialized, allocate Databases (DBs) to it.

  At the Satellite:

• Define the DB Common Set.

• Run the Interdisciplinary Project Setup function to create the MDBs

Common Databases

Databases that are not created as part of the Interdisciplinary Project Setup need to be included in MDBs in order to provide access Tags data. The relevant Dictionary databases must be included in MDBs with the Tags data. Design and other databases may also be required.

It is possible to create a DB Set to hold these Databases which will be referenced at Project Setup time. The DB Set is created using existing Administration DB Set functions, and should contain only those Databases that are to be included in the MDBs. The order of the databases in the DB Set is reflected in the order of databases in each MDB.

Baselines

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. Baselines may be created at any time after the initial project configuration has been defined. In practice they are likely to be created at key project milestones.