AVEVA Clash Manager™ 14.3 User Guide
Design Workflow : Housekeeping Tasks
Housekeeping Tasks
•
Following 3D Model Changes
•
At Project End
•
Roles of the Discipline Designers
•
AVEVA Clash Manager Configuration
•
Automatic Assignment Rules
•
Automatic Acceptance Rules
•
Status
•
Clash Sets
•
Log Files
•
Project-wide Clash Status Reporting
Following 3D Model Changes
When the 3D model has been substantially updated, the clash details remain in the AVEVA Clash Manager database (not the 3D model database) even though the item(s) they refer to have been removed. In these circumstances, the particular clash details continue to be reported until all Clash Sets containing the detail have been rerun.
These clash details, including their comments, can be removed from the AVEVA Clash Manager database by using the Delete all Unreferenced Groups and Elements and Comments functionality available from the AVEVA Clash Manager Configuration window. Refer to Delete unreferenced data for further information.
This process removes historical data and consequently the original comments will have been lost, if the clash re-appears.
At Project End
At the end of a project all clash report data and history data can be removed from the database by using the Delete All Clash Data, Comments and History functionality available from the AVEVA Clash Manager Configuration window. The configuration data and clash set definitions, check list and obstruction list all remain. The remaining data is truncated to recover unused space in the Oracle Table Space. Refer to Delete ALL Clash data including Comments and History for further information.
Roles of the Discipline Designers
AVEVA Clash Manager includes a security model that enables the administrator to specify the users who are to be the Members and Supervisors of each discipline and then to specify whether members or supervisors of particular disciplines may change Clash Status, acquire Clash Ownership, perform Clash Checks of the Current Element and/or add Comments to clash records (refer to Access Rights for further information).
Depending on the size and scope of the project, the administrator needs to decide what role the discipline designers will take in the clash resolution process. Typically, there are three approaches that can be taken:
•
ALL discipline designers have access to the AVEVA Clash Manager reports and are responsible for ensuring the clash free status of their part of the 3D model. This approach is most suitable for medium to large projects where a large clash data set is anticipated and requires frequent review by all designers on a part time basis. For this approach, the Security Levels tend to be towards the Low state.
•
Discipline supervisors or a small number of nominated discipline designers are given access to the AVEVA Clash Manager reports. These users are responsible for ensuring the clash free status of their discipline’s part of the 3D model. This approach is most suitable for small to medium projects where a small team of users can adequately manage and review the AVEVA Clash Manager reports on a part-time basis. For this approach, the Security Levels tend to be at the Medium state.
•
An overall clash coordinator is responsible for ALL clashes on the project and is tasked to review the AVEVA Clash Manager reports and perform clash resolution in consultation with discipline designers. This approach is most suitable for small projects where only a small clash data set is anticipated and can be easily handled by one person on a part time basis. For this approach, the Security Levels tend to be towards the High state.
The approaches described above are for guidance only but are typical of those taken by existing users in the deployment of AVEVA Clash Manager. The administrator may decide to adopt one of the above approaches, or formulate their own solution to match specific project requirements.
AVEVA Clash Manager Configuration
Before AVEVA Clash Manager can be used on a project, it is necessary for you to perform some configuration tasks. The focus of these tasks is to produce an organised and structured presentation of clash data that assists in the management of the clashes. All configuration tasks described here are carried out at the AVEVA Clash Manager Configuration window.
The basic configuration tasks, which are necessary regardless of project size, are as follows:
•
Project – user-id, password
•
Discipline – determines how disciplines are identified for the clashing elements
•
Security – controls user, supervisor and administration access rights
•
Group – controls group settings for consolidation of detail clashes
•
Assign – determines how clashes can be automatically assigned to a discipline.
The above tasks should serve for small to medium sized projects, with the remaining advanced configuration tasks namely, Accept, Class, Priority, Status, Comments, Level/Type and Gtype/Tracking, safely left at the default values.
For larger projects, the advanced configuration tasks should be carried out, to achieve complex assignment and acceptance rules.
Automatic Assignment Rules
In order to set up successful assignment rules the administrator needs knowledge of how the 3D model is structured and how each discipline will model design items. The administrator needs this to determine the best set of rules for the specific project. Typically, the following situations are considered when formulating the automatic assignment rules:
•
Access-ways and Escape routes
•
Issued Pipes
•
Exotic Materials
•
Primary Steelwork
•
Issued Secondary Steelwork
•
Tertiary Steelwork
•
Stress Critical Pipes
•
Issued Elements
•
Electrical Lighting
•
Electrical and Instrument Stands
•
Withdrawal Volumes.
As the project progresses and AVEVA Clash Manager is used in earnest, it is inevitable that the administrator will need to either modify or add to the clash assignment rules. It may be necessary to recompute all or some of the clashes in the database to take account of the new rules.
Automatic Acceptance Rules
Automatic clash acceptance can save a lot of time for the project, removing the need for the designers or clash coordinators to review and approve acceptable clashes. To set up successful acceptance rules for a project, the administrator needs knowledge of how the 3D model is structured and how each discipline will model design items.
The following list contains some example situations where specific acceptance rules may be applicable:
•
All Soft/Soft – Touch, Clear, Clash
•
Architectural Fittings with Architectural Walls – Touch, Clear
•
Supports with Main Steelwork – Touch, Clear
•
Structural with Structural – Touch, Clear
•
Supports with Stair ways and Ladders – Touch, Clear
•
Stair Ways and Ladders with Any Other Discipline – Touch, Clear
•
Lay Down Areas with Any Other Discipline – Touch, Clear
•
Handling Ways with Handling Ways – Touch, Clear, Clash
•
Main Escape Ways with Main Escape Ways - Touch, Clear, Clash
•
Secondary Escape Ways with Secondary Escape Ways - Touch, Clear, Clash
•
Access Ways with Any Other Discipline – Touch, Clear
•
Escape Ways with Any Other Discipline – Touch, Clear
•
Penetration Sleeve with Any Other Discipline – Touch, Clear
•
Support with Piping – Touch, Clear
•
Spray Volume with Spray Volume – Touch, Clear, Clash
•
Hazardous Areas - Touch, Clear, Clash.
Note:
The automatic acceptance facility does not only approve clashes. It can be used to set a clash to any standard status, namely:
•
Unknown
•
Unapproved
•
Pending
•
Conditional
•
Approved.
Status
The standard clash status values that AVEVA Clash Manager uses to categorise a clash are as follows:
•
Unknown – an initial or default status applied to new clashes if none of the automatic acceptance rules are triggered
•
Unapproved – the clash has not been reviewed and remains as a valid or outstanding clash for the project
•
Pending – this status is used to indicate that the clash is currently under review by the design teams
•
Conditional – this status is used to indicate that the clash has been reviewed and resolved in the 3D model. This also implies that following the next clash run this clash will no longer appear in the clash report. For reporting purposed this status implies a resolved clash
•
Approved – this status is used to indicate that the clash has been reviewed and is considered acceptable by the design team. The clash will continue to be reported in subsequent clash runs, but its approved status will remain with the clashing items throughout the remainder of the project lifecycle.
For the purpose of evaluating the worst case the standard status always appear in the order shown above, the worst case being at the top of the list.
User-defined status can be inserted into the list to suit specific project requirements. The use of these status can be restricted to specific disciplines, or users. For example, status could be inserted as follows:
•
Piping to Verify – a conditional approval to be used by the PIPING discipline only. This status may be used by the clash coordinator who has conditionally accepted a number of clashes on behalf of the PIPING team. Setting the status to this new value makes it easy for the PIPING team to filter on this status on the clash reports and therefore to review all clashes conditionally accepted on their behalf
•
For Design Review – a pending status for use by all users. Clashes with this state require further investigation or discussion at the next design review meeting.
Clash Sets
It is recommended that the number of Clash Sets for a project is kept to a minimum.
There are no limits on how the Clash Sets are structured, for example, by area, discipline, design status or combinations of these. The following examples show how Clash Sets have been configured:
•
By design area and discipline – with structural as the obstruction and all other disciplines checked against the structures
•
By design discipline and design status – with disciplines checked against each other based in model design status. An example of this approach is to only clash check items with built or checked status
•
By design area/sub-area, discipline and design status – for a large project, it may be necessary to subdivide design areas into smaller sub-areas, strips or modules, in order to complete a clash set or series of clash sets overnight, in batch mode. These smaller Clash Set runs execute quickly, but incur additional administrative overhead to coordinate the Clash Set execution.
It is recommended that the administrator constructs their own Obstruction, Check and Exclude lists using wildcards, where possible. This reduces the amount of administration required during the life of the project, because, as sites, zones or elements are added or deleted from the design databases, they will be automatically included or removed from Clash Set lists that use wildcards.
AVEVA has seen a number of situations where clients have started a project with a large number of clash sets (x100s) and, through experience gained during the life of the project, have rationalised these down to a more manageable number (x10s). Therefore, before implementing AVEVA Clash Manager, think carefully about the approach you will take when defining your Clash Sets, and make sure the number of Clash Sets is kept to a manageable size.
Log Files
Following execution of a clash set, the administrator can check whether the process is successful by interrogating the log files that are generated. The log files for a clash set run are created in a directory the folder used by AVEVA Clash Manager during a clash run.
%TMP%\PCLAM.<project>.<clashSetIndex>
For example %TMP%\PCLAM.APS.25
Note:
It is slightly different to the previous version which included the users windows username. The location of the temporary system files, the files were found in the directory: Pclam_’project code’_’windows_username’_’clash_set_number’.
There are five files generated by the clash set, and a series of output files; one for each checked element. The names and purposes of the files are as follows:
•
pclam_LOAD.LOG and pclam_RUN.LOG - Log files of the RUN and LOAD Processes
•
pclam_rundata.xml - Datafile communicates key values to the RUN and LOAD processes
•
pclam_nnnn.OUT, pclam_nnnn.LOG and pclam_nnnn.FIN - Outfile files generated for each checked element.
Project-wide Clash Status Reporting
In order to keep project management aware of the 3D model’s clash status, it is important to generate regular clash status reports. There are a number of ways of doing this and any combination of the methods described here can be utilised:
•
Track Changes – this creates milestones in the AVEVA Clash Manager database to allow filtering of statistics on the main AVEVA Clash Manager bar charts. This also allows rudimentary clash trend analysis to be performed. The bar chart graphics directly cannot be saved directly, however a third-party screen capture tool can be used to do this. Alternatively, statistics can be saved in csv format for import into Excel, or similar spread sheet application, as described below
•
Microsoft Excel – a number of clients are using this method to great effect to produce detailed statistics for clash status. An example of how this can be achieved is to take a daily or weekly save of the main window statistics and load these into an Excel sheet. This data can then be used to produce detailed trend analysis reports, using Excel’s in-built charting and statistical functions
•
'Screenshots’ – Simply take regular screen ‘shots’ from the main AVEVA Clash Manager bar chart display.
1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.
AVEVA Logo