What the Pdms 2 Scoring Manual Actually Is
It's not a scoring system for students. In the context of AVEVA PDMS, the Pdms 2 Scoring Manual is a reference document that defines how automated design audits and clash detection results are quantified during model quality reviews. When you run an automated audit against a plant model, every flagged item gets a severity score. The manual tells you what those scores mean, what thresholds trigger warnings versus errors, and how to interpret the final composite rating. I spent about three weeks chasing down why a piping subsystem kept returning a deceptively low audit score even though the model was clearly non-compliant with our client's specification. The issue came down to how the scoring weights were configured in the project setup versus what the manual assumed as default. Once I traced it back, the fix was straightforward but not obvious unless you've actually opened the audit configuration editor. More on that later.
Pdms 2 Scoring Manual: Where It Lives and How to Access It
The manual ships with the PDMS installation but is often buried under several subdirectories. On a typical Windows install it sits somewhere under the AVEVA directory structure, usually nested within the documentation folder. If you installed PDMS locally it should be available without needing an active network license, which matters when you're working from a remote site or a guest machine. In practice I just search for "scoring" from the Start menu and open the PDF directly from the results. It's more reliable than hunting through the software's help system. The document itself is dense. It's not written for beginners. It assumes you already understand how PDMS organizes model data, what an audit rule set is, and how severity classifications work. If you're new to PDMS you'll want to start with the base training materials before opening this. Reading the scoring manual first is like trying to read a dictionary cover to cover. Possible, but inefficient.
How the Scoring System Actually Works
Every audit rule in PDMS has an associated severity level. The manual maps those levels to numerical scores. A missing support might be weighted differently depending on whether it's on a critical pipe run versus a secondary drainage line. The composite score is calculated across all flagged items in a subsystem, and the final rating determines whether the model passes, needs revision, or fails outright. The exact thresholds are configurable per project, which is both a feature and a source of confusion. One thing the manual doesn't emphasize enough: the scoring is cumulative. If a single pipe run has fifty minor flagging items, the total score for that run can look worse than a different run with five major violations. This reverses intuition. People often assume that one serious error is worse than a hundred small ones, but the PDMS scoring engine aggregates everything linearly unless you override the weighting. I learned this the hard way when a junior engineer pushed back on an audit result, claiming the model was fine because the only flagged item was supposedly low severity. The aggregate score told a different story.
Get the Full Details
Common Misunderstandings and a Real Problem I Faced
The biggest mistake I see is treating the scoring output as a definitive judgment of model quality. It's not. It's a snapshot based on whatever rules are active in the current rule set, and rule sets vary between projects. A model that scores well in one project environment might fail in another simply because different audit criteria are loaded. Always check which rule set was applied before accepting a score as final. Here's a specific case. I was auditing a pump skid layout for a client who required an aggregate score above a certain threshold. The skid scored borderline failing. I opened the detail and found that roughly forty percent of the flagged items were false positives caused by a misconfigured clearance rule for instrument tubing. The rule was set to check clearance between instrument lines and structural members at sixty millimeters, but the actual project requirement was thirty millimeters. The mismatched threshold was doubling the apparent violation count and tanking the score. The workaround was to create a custom exclusion filter. Instead of changing the global clearance rule, which would have affected every model in the project, I scoped the exclusion to just the instrument tubing category on that specific skid. This brought the aggregate score into compliance without compromising the audit integrity of the rest of the model. It took about forty-five minutes to set up properly. Without the exclusion, we would have had to manually review every flagged item, which would have taken half a day at minimum.
Advanced Nuances Beginners Miss
The scoring manual covers the basics, but there are a few things that don't get mentioned. First, the audit engine caches previous results. If you run an audit, make a change, and run it again without clearing the cache, you might see outdated scores. This happened to me on a Tuesday when I spent twenty minutes confused about why the score improved after what looked like no change. The cache was the issue. Clear it between major revision cycles. Second, subsystem-level scoring doesn't automatically roll up correctly to the parent area in complex models. If your model has nested subsystems with different audit rule sets applied, the parent score can appear artificially inflated because the child-level violations aren't being weighted properly in the aggregation. I've seen whole disciplines pass an audit because the rollup was broken, then fail when a separate reviewer ran the same audit from a different workgroup. Always verify the rollup by drilling into the child subsystems individually rather than trusting the top-level number.
Limitations You Should Know About
The Pdms 2 Scoring Manual describes a system that works well for routine compliance checks but has blind spots. It cannot evaluate engineering judgment. A pipe route might score perfectly while being completely unbuildable because of maintenance access requirements or constructability issues that aren't captured in any automated rule. The scoring is narrow by design. It measures rule compliance, not design quality. Another limitation: the scoring thresholds are arbitrary without project-specific calibration. A score of 85 might be excellent in one project and marginal in another. The manual provides default thresholds but explicitly states they should be adjusted based on project requirements. Using the defaults unmodified on a client project is a recipe for disputes. I recommend spending the first week of any new project calibrating the thresholds against a sample model before relying on them for any official review. If you need comprehensive design evaluation beyond what the scoring manual covers, you'll need to supplement it with manual reviews, clash reports, and constructability assessments. The scoring tool is a screening mechanism, not a replacement for engineering review.
Practical Steps to Get Started
Open the manual from your installation directory and read the sections on severity classification and rule weighting first. Skip the appendices. Then configure your project audit rules to match your client's specifications before running any automated audits. Test the configuration on a small subset of the model and compare the output against what you expect. If the scores look wrong, check the rule set, the exclusion filters, and the cache status in that order. That covers most issues without needing to dive deeper into the manual.
