Abstract
The core principles of collecting good quality data from site for creating CCTV inspection reports including some explanations of how to avoid common mistakes.
Author
Steve Peregrine BEng Hons, Senior Technical Manager
Page Contents
Chapters
The PLR Naming Convention
Most global drainage inspection standards include a system for naming pipes based on either the upstream manhole ID or a combination of both the upstream and downstream manhole IDs. The Manual of Sewer Condition Classification (MSCC) defines the naming convention for WRc pipe and sewer inspection using the Pipe Length Reference (PLR) system at all times:
Takes the upstream node ID and adds the PLR Suffix to the end.
This is consistent at all times throughout all WRc style reporting and is automatically applied by software applications such as WinCan VX. The PLR Suffix is simply an incrementing letter starting at X, so is X, Y or Z, where X is the most common, and often overlooked by CCTV report writers and inspectors.
Basic single pipe setup.
In a simple straight forwards drainage system and in most cases with foul drainage systems, there is only one pipe leaving chamber MH1, so the PLR of that pipe becomes MH1X. This is the ID of the pipe, so when we talk about pipe MH1X, it is clear from the drawing which pipe this is, because it is the outgoing pipe from chamber MH1 and it doesn’t matter where it goes or what the downstream chamber’s ID is.
This logic happens all the time inside inside WinCan VX with WRc projects and a lot of people ignore the PLR field and the PLR Suffix field inside the section header because the PLR Suffix defaults to X for all new pipes, and the PLR itself is created automatically when the header is saved.
The big problems with CCTV inspection data begin when people use inappropriate naming conventions for the nodes in their project, and fail to follow the guidance warnings on screen that they are creating duplicate assets. Here is an example of common bad data:
The start of data problems.
So, the user creates a drawing or starts to create headers inside the software application to inspection this network of pipes. They are going to inspect:
MH1 upstream to gully GY.
MH1 downstream to MH2.
MH2 upstream to gully GY.
Now let’s see what happens when we add the PLRs to this drainage network:
Look carefully at the PLRs.
Look first at the PLR for the pipe from MH1 to MH2. It looks good. As explained, we take the upstream manhole ID and add the X to the end giving is MH1X.
But now look at the PLRs for the two gully legs. Notice that they are both GYX. Why? Because the upstream node ID of both pipe is GY, so the PLR of both pipes is GYX:
Duplicate PLRs.
What does this mean in plain and simple terms? This means that there are 2 pipes with the same ID, so these are both the same pipe. But, I hear you say that, “They are not the same pipe because one goes to MH1 and the other goes to MH2.” Back to basics - the PLR is defined by the Upstream node ID and the PLR Suffix, and the downstream node ID has no affect on the PLR whatsoever.
WinCan VX will warn the user that they are creating a duplicate asset (remember, the PLR is the ID of the asset), but it will also allow them to ignore the warnings and carry on. The reason for this is there are a small number of drainage inspection standards around the world that do not define a naming convention for pipes, but not many.
How do we avoid problems like this? The simple solution is to use unique IDs for every node point on your site sketch regardless of whether it is a manhole, catchpit, gully, rainwater pipe or anything else. There is no specified way to do this, but a simple and robust technique is to use a few letters and a number which additionally describe the use of the asset (i.e. foul water, surface water or combined) and its type, like this:
Node Type | Foul Water ID | Surface Water ID | Combined Use ID |
|---|---|---|---|
Manhole | FWMH1, FWMH2 etc | SWMH1, SWMH2 etc | CWMH1, CWMH2 etc |
Inspection Chamber | FWIC1, FWIC2 etc | SWIC1, SWIC2 etc | CWIC1, CWIC2 etc |
Gully | FWG1, FWG2 etc | SWG1, SWG2 etc | CWG1, CWG2 etc |
Yard Gully | - | YG1, YG2 etc | - |
Road Gully | - | RG1, RG2 etc | - |
Soil & Vent Pipe | SVP1, SVP2 etc | - | - |
Rain Water Pipe | - | RWP1, RWP2 etc | - |
Catchpit | - | CP1, CP2 etc | - |
Soakaway | FWSK1, FWSK etc | SWSK1, SWSK2 etc | CWSK1, CWSK2 etc |
Rodding Eye | FWRE1, FWRE2 etc | SWRE1, SWRE2 etc | CWRE1, CWRE2 etc |
Fresh Air Inlet | FAI1, FAI2 etc | FAI1, FAI2 etc | FAI1, FAI2 etc |
Ground Floor Toilet | WC1, WC2 etc | - | - |
Lamphole | FWLH1, FWLH2 etc | SWLH1, SWLH2 etc | CWLH1, CWLH3 etc |
Septic Tank | ST1, ST2 etc | - | - |
Cess Pit | CE1, CE2 etc | - | - |
Grease Trap | GT1, GT2 etc | - | - |
Petrol/Oil Interceptor | PI1, PI2 etc | PI1, PI2 etc | PI1, PI2 etc |
Connector Node | CN1, CN2 etc | CN1, CN2 etc | CN1, CN2 etc |
Outfall | - | OF1, OF2 etc | OF1, OF2 etc |
Inlet | - | IN1, IN2 etc | - |
Unknown | UKN1, UKN2 etc | UKN1, UKN2 etc | UKN1, UKN2 etc |
This list can be extended or modified as required by the user because it is only a suggestion for a simple and robust naming convention that is easy to follow and is informative. It should be remembered that the upstream and downstream node ID fields in the WRc reporting in WinCan VX only allow for 10 characters maximum. The reasons for this are because the manhole naming convention described in Appendix A of the MSCC only require 10 characters to name any manhole in the country, and the xml data format exchange file also limits this field to 10 characters. This naming convention is described in detail in Understanding STC25 Manhole References.
In short, the really easy way to fix the commonly seen data problems like that describe above is to use numbers in the gully (or whatever upstream node exists on site) references, like this:
Good data with no duplicate PLRs.
The most common time that we see data problems like this is when people inspect upstream from an inspection chamber on site (let’s call it MH1) and they push the camera up 2 or 3 branch lines coming into chamber MH1. They label the upstream node as LatA, LatB and LatC, which then means that the PLRs are LatAX, LatBX and LatCX. So far, so good.
But now they move on down the main line to MH2 and do the same thing again starting at A, so they inspect from MH2 upstream to LatA and LatB, making the PLRs LatAX and LatBX. Now we have 2 LatAX and 2 LatBX in the project and already the data is starting to fall apart. And of course they will swear blind that the pipes are different pipe because they are connected to MH1 and MH2, but this is just not the case in the data. The data sees them as the same pipe because they have the same PLR.
Some pointers to help you demystify the nomenclature:
‘LatA’ describes a pipe, but the field in the WinCan header is ‘Upstream Node’, it is not ‘Pipe ID’. So, you should be entering the node ID of the object that is that the upstream end of this pipe and not some kind of lazy shortcut ID for the pipe. So, something like SVP1, WC3 etc is much more appropriate and then simply keep incrementing the number part for every SVP or WC found on site. The correct PLRs will fall out naturally in the wash with ease and with no pop-up warnings in WinCan VX.
The software does not work by considering ‘start’ and ‘finish’ points of an inspection. This is an old concept that was discarded a long time ago in nearly all global inspection standards in favour of ‘upstream node', ‘downstream node’ and ‘inspection direction’. The upstream and downstream nodes of a pipe are attributes of the pipe itself and are not affected by the inspection. An inspection of this pipe can be ‘upstream’ or ‘downstream’, but it does not change the fact that the upstream end of the pipe is Node1 and the downstream end is Node2. Consider a pipe flowing from MH1 to MH2:
Upstream Node = MH1
Downstream Node = MH2
Inspection direction can be either Upstream or Downstream
Because the name of the pipe (the PLR) is defined by the upstream node ID and the PLR Suffix, this allows a manhole or other node to have up to 3 outgoing pipes. This may seem a strange concept to many CCTV inspectors, particularly at a domestic level because they have very likely never seen a manhole with 2 or more outgoing pipes. However, this is extremely common in highways drainage and is constructed this way by design because on highways (more than any other place) it is essential to get the water off the road at all costs and as quickly as possible during heavy rainfall events so as to avoid traffic accidents. Those inspecting highways drainage will commonly come across drainage designs like this as an example:
Multiple outlets.
Now the manhole MH1 has 3 out going pipes, so this is where we start to adjust the PLR Suffix value. By default it is always X, and in cases like this, the X PLR should always be the ‘most significant’ outgoing pipe (i.e. most likely the deepest and the largest outgoing pipe).
Then, we use Y (maybe Z as well) to name the other outgoing pipes as MH1Y and MH1Z (remember. the PLR only considers the upstream node and the PLR Suffix).
There is no hard and fast prescribed way of deciding how to use which PLR Suffix for each pipe except that the X pipe should always be the primary outgoing pipe. After this, you can select to name the PLR Suffix for the other outgoing pipes by:
Rising up through the manhole from the bottom (will be explained why this makes sense in the next paragraph) as shown in the diagram above, so the Y PLR is the next highest one from the X, and the Z PLR is the highest one.
Going clockwise around the manhole from the X position (in the example above, the Y and Z PLRs would be swapped over).
Random selection. This is not recommended, because all that matters is that every pipe in the project has a unique PLR, and contractors should be consistent with how they manage and deliver their data across all projects and customers.
What if there are more than 3 outgoing pipes?
The chances of this are extremely rare but not impossible. At the time of writing this, the author has only ever come across a manhole with 4 outgoing pipes once (after 30 years in the business), and yes it was on a highways project. There is known to be a surface water manhole in the North West of England which has 7 outlets. All 7 outlets go to the same next manhole through a syphon to the other side of a river, and the 7 pipes in the upstream manhole are all along one wall and at ever increasing heights from the bottom of the chamber so that the rain water flows first through pipe 1, then through pipe 2 etc as the level of rainfall increases or pipes have failed.
The MSCC simply advises the user to use whatever character they wish after Z. The issue we have here is that under MSCC rules, this can only be one character (because the xml data format has a limit of 11 characters on the PLR value - 10 for the upstream node plus the PLR Suffix).
Then additionally, we have the very old (bit still regularly used) STC25 manhole reporting system which specifies incoming pipes as A, B, C, D etc, so using A as a PLR Suffix for an outgoing pipe may be misleading.
It is recommended to go back to the letter W and then start going backwards from there for outgoing pipes 4 and upwards (i.e. X, Y, Z, W, V, U etc).
Why is the highways drainage system shown above been constructed this way?
We never really know how hard it is going to rain when it rains and highways are impervious so they create an awful lot of runoff water which we need to catch and get away from the highway surface as quickly as possible to protect driver’s lives.
Under a normal light to medium rainfall event, the water will come into the system and run away down the X pipe MH1X without any drama.
But, what if it is raining extremely hard or pipe MH1X is blocked with silt (common on highways drains). Ok, no drama, the manhole MH1 will fill up a bit with water and then the additional rainwater will start to flow down pipe MH1Y.
Now what if it is either raining harder than ever before in a ‘once in a hundred years rainfall event’, or both the MH1X and MH1Y pipes are blocked or the CP1X pipe is blocked. The highways engineers still want to get the water off the road, so now the chamber MH1 will fill up until the water starts to flow down the MH1Z pipe, which as you can see goes off in a completely different direction to a a different part of the drainage network because the chances of 2 different parts of the network failing at the same time are very slim, but not impossible.
This is great idea which includes built in resiliency into the drainage network and usually works well, except that during normal operational conditions, we are only alerted to a problem when all three pipes are blocked or failed, so the remedial works will be much more significant than if there is only 1 outgoing pipe.
HADDMS Pipe Referencing
The HADDMS inspection standard follows the same PLR Suffix naming convention of Upstream Node plus PLR Suffix, except that it does not X, Y and Z for the PLR Suffix. Instead, it uses a dot and a numeric incremental counter like .1, .2, .3 etc so the MH1X pipe in the diagram above would be MH1.1, MH1Y is MH1.2 and MH1Z is MH1.3.
The HADDMS data format system does not consider the WRc xml file data and specifies its own limits for the number of characters allowed on nodes and pipe IDs, so the use of 2 characters here is of no consequence in this data system.
Other than that, the logic is exactly as described here.