Understanding How PDMS 2 Scoring Actually Works
The PDMS 2 scoring system is built into the design review workflow within AVEVA (formerly DATUM) PDMS 2.0. It provides a numerical framework for evaluating design compliance, clash severity, and discipline coordination issues during multi-discipline reviews. The manual itself walks through how to set up scoring criteria, assign weights, generate scores, and export results for stakeholder sign-off. Most people treat it like a checkbox exercise, but the results are only as good as the criteria you define. The online version of the manual lives on the AVEVA documentation portal. You can access it at docs.aveva.com once you have a registered account. The PDF you download is version-dependent, so make sure you are matching the scoring module version to your PDMS 2.0 release. The 18.1 release and the 21.x releases handle scoring metadata differently, and mixing the two will give you confusing export results. I use the scoring module for pipe versus structural clash triage on offshore platform redesigns. The standard workflow goes like this: you open the design review workspace, load your disciplines, select the scoring template, run the clash detection, then map the results to your scoring grid. The grid itself lets you assign penalty points per clash type. Hard clashes get the highest weight. Near-misses and clearance violations follow on a sliding scale. Soft clashes with routing flexibility are at the bottom.
Here is where it gets tricky in practice. The default scoring template in PDMS 2 assumes equal weighting across all three dimensions of clash. That sounds reasonable until you are working on a tight pipe rack where vertical clearance matters three times more than lateral interferences. I learned this the hard way on a platform modification project in 2022. The scoring engine flagged twenty interference items along a cable tray route. All scored equally. The review team spent an hour arguing over low-priority lateral clashes while a real structural penetration issue sat unscoring because it was buried in the noise. The workaround is straightforward if you know where to look. Go into the scoring criteria editor, select the rule set for your discipline combination, and override the dimensional weight factor manually. Set the vertical axis weight to 2.5 and the lateral axes to 1.0. Save it as a custom template. Run the clash again. The same twenty items showed up, but now the structural penetration ranked in the top three. The export file reflects the new weights immediately. One thing the manual does not emphasize enough is how scoring interacts with PDMS 2's exclusion zones. If you have already defined exclusion volumes around sensitive equipment, the scoring engine will still generate raw clash points for those zones unless you explicitly enable the exclusion filter in the scoring rule set. I missed this on my first few runs. The score file came back looking terrible even though the design was actually clean. The fix is in the rule configuration screen under Clash Processing Options. Toggle Exclude Volumes to On, then re-run the scoring pass. Cuts false positives by about sixty percent on typical layouts.
The export formats matter too. You get three options: XML, CSV, and the native PDMS review format. The XML output includes full metadata about scoring weights, rule sets, and timestamps. Useful if you need to audit your process for client sign-off. CSV is lighter but strips most of that context. Native format ties back directly into the design workspace, so changes you make in review update the score automatically. Pick the format based on who is receiving the report. Owners usually want XML. Discipline leads prefer CSV. Your own coordination team should work in native format. There are limitations you should know about upfront. The scoring module does not handle discipline boundary ambiguity well. If a pipe supports a beam and a cable tray at the same node, the engine has to pick which discipline pair owns the clash. It defaults to the first discipline loaded in the review workspace. That means the order in which you import your models can change the entire scoring distribution. Always load structural first, then piping, then electrical and instrumentation. That gives the engine the most logical hierarchy for resolution. Another bottleneck is performance. Scoring a full mid-platform model with six disciplines running at standard clearance settings takes roughly forty-five to ninety minutes on a workstation with sixteen cores and sixty-four gigabytes of RAM. If you are iterating on the same model repeatedly, cache the clash results and only re-run scoring when something changes. The manual covers this but buries it in a subsection most people skip.
Get the Full Details
If your project involves multiple revision levels or you need traceability across design phases, the scoring module alone will not give you that. It tracks changes within a single review session, not across versions. I pair it with an external tracking spreadsheet for those cases. Column one gets the unique clash ID from the scoring export, column two gets the revision tag, column three notes whether the item was resolved, deferred, or accepted as-is. It takes maybe five minutes to set up and saves you from losing track of what was agreed to in each review cycle. Bottom line, the scoring manual covers the mechanics well. The gaps are in configuration choices that depend on your project type and client requirements. Start with the default template, understand what each weight controls, and customize aggressively before the first major review. Your scores will actually mean something.
