Pipeline Inspection Tools in a 3D Environment

Transcription

1 Pipeline Inspection Tools in a 3D Environment By Lars Dall, Survey Manager, EIVA A/S Abstract The implementation of pipeline inspection functionalities in EIVAs 3D modelling tool, NaviModel3, has brought together a series of tools on a single platform. The tools can be used either simultaneously or one-by-one in a fully integrated solution, that has been developed with focus on 3D visualization in order to provide a highly intuitive and optimized environment for the post-processing. The solution includes: Cleaning functionalities, automatic- as well as manual methods Conventional Digital Terrain Modelling tools in a 3D environment Comprehensive 3D visualization functionalities Dedicated pipeline inspection functions: Pipetracker functions Digitization functions Automatic placing of the pipe object Generation of cross-profile side-flags, standard- as well as user defined Video integration Offline eventing Generic exporting functionalities Key words: Pipeline inspection, data modelling, optimization and practical efficiency, automatic cleaning, data modelling, video integration 1. Introduction The optimization of the post-processing environment for pipeline inspection post-processing tasks within NaviModel3 has focused on two aspects: Optimization of the visual environment in order to supply the operator with enhanced and improved background information for his decision making Speed-optimization and automation of the entire post-processing task The objective of the optimization has in other words been to supply the users with tools that facilitates the production of better and more unambiguous pipeline inspection related data, faster and with reduced user intervention. For the optimization of the visual environment, a series of new features have been implemented. In the development phase of NaviModel3, it was regarded an important enhancement to the visual environment to be capable of displaying all data of relevance in an integrated 3D based DTMwindow, with video functionalities being integrated into the visualization of the data. Of particular interest in connection with pipeline inspection tasks is furthermore elements that will improve the visualization of the pipe object. The speed-optimisation and automation has also had a series of focus areas. With pipe-line inspection to a large extent depending on reliable and accurate seabed information, some kind of fast, reliable automatic cleaning of the seabed scanning data must be regarded a necessity. Also the fact that NaviModel3 has an unlimited model-size is expected to be a significant contributor to the speed-optimisation. EIVA A/S Page 1

2 The objective of this paper is thus to describe the various tools introduced within the NaviModel3 framework, in order to drive the desired optimization as well as to subsequently substantiate that the objectives of the optimization have been met. 2. NaviModel3 The NaviModel3 DTM modelling software is a tool for the generation of and manipulation with Digital Terrain Models (DTMs) on the basis of either single- or multi-beam based bathymetric data. The modelling is founded on either Triangular Regular Network (TRN) or on Triangular Irregular Network (TIN) algorithms. The TRN geometry type models consist of equally spaced triangular cells, whereas for the TIN geometry type models, triangles are based on the raw data. A series of dedicated add-on modules that are designed for specific tasks, have been developed for inclusion in the modelling tool. These comprise: Online 3D module. This module facilitates visualization in an online environment in which various objects can be shown in real time and superimposed onto a DTM Catenary module that facilitates a variety of catenary based tools, as well as calculations and visualizations associated with pipe- and cable-laying jobs Pipeline inspection module. The subject of the present paper Figure 1 The EIVA Pipeline Inspection Postprocessing Flow Figure 1 shows the flow for a typical pipeline post-processing task. Input data is originating from the on-line and editing phases. Furthermore video- and event-information, originating from external sources, can be imported. NaviModel3 hosts different tools, for cleaning, visualization, determination of the pipe etc., that are used in combination with external utilities for offline eventing and automatic cleaning. Ultimately, in order to make the pipe data available for further processing and documentation, a series of generic and predefined exporting functionalities have been implemented. 3. The Quad Tree Principle Within NaviModel3, data is, in general terms, organised in a so-called Quad Tree structure. A Quad Tree is a tree-based data structure in which each internal node has up to four children. Quad Trees are commonly used to partition a two dimensional space by recursively subdividing each level into four quadrants or regions as visualised in the figure below. In a Quad Tree, records are stored in locations called leaves. The name originates from the fact that records always exist at end EIVA A/S Page 2

3 points; there is nothing beyond them. The 1st level is also sometimes termed the root. Branch points, on the other hand, are called nodes. The order of a tree is the number of branches per node. In a Quad Tree, there are always four children per node, so the order is 4. The number of leaves in a Quad Tree is consequently always a power of 4. The number of access operations required to reach the desired record is called the depth of the tree. Figure 2 visualises a Quad Tree of depth 4. In a practical Quad Tree, there can be billions of records. As can be seen in the figure, not all leaves necessarily contain a record and the same is actually the case for nodes. In the latter case, the node does not have to be subdivided. When a leaf does not contain a record it is called a null record. In the example shown here, seven out of 64 leaves are nulls, indicated by open circles. Figure 2 Quad Tree with Leaf Level Within NaviModel3, the higher orders of the Quad Tree are primarily used for visualization purposes: the higher the scale the lower the requirements to the resolution and thereby the higher in the Quad Tree the data can be assembled. When exporting from a DTM, the leaf level data are normally used to define the various attribute values for the export. The cell size for the exporting is however used to optimize the exporting: if for instance the cell size for the export is 2 times the cell size of the model, then the exporting function will actually collect attribute values from the level above the leaf level. This will potentially speed up the export by a factor 4. In NaviModel3 a database that encloses the hierarchical organisation of the Quad Tree structure has been entrenched in a single file solution. With this type of organisation of data, a high degree of I/O efficiency is required from the system, with I/O efficiency defined as the speed by which data is moved between internal memory and storage media, primarily when the user pans or zooms in the model or when a new model is loaded. Whereas the loading of a model can be accomplished in less than 1-2 seconds, irrespective of size, moving and panning can be conducted seamlessly, without the user noting that the system accesses the disc in order to update the view in accordance with changes in scale and position. 4. Geometry Types and Interpolation Methods A Digital Terrain/Elevation Model (DTM/DEM) can be regarded a generalization of the observed bathymetric data, with generalization being defined as the process of reducing the amount of detail in a map in a meaningful way, with respect to scale. At the same time, since total model coverage of the area of interest is often a requirement, the model must often be extended beyond the observations. Whereas different geometry types are used to generalize on the basis of the bathymetric observations, interpolation methods are utilized to generate qualified information, based on the observations available, in areas where no observations have taken place. NaviModel3 supports two different geometry types: The Triangulated Regular Network (TRN) geometry type The Triangulated Irregular Network (TIN) geometry type Only the TRN geometry type is of relevance in the present context. EIVA A/S Page 3

4 TRN Modelling The TRN geometry type is based on square cells with a given cell size. The cell attribute value (zvalue or depth value) can either be arrived at by averaging all the observations within a single cell or by taking the minimum or maximum depth value respectively. The TRN geometry method produces all three model types by default. So when generating a DTM within the NaviModel3 framework, the first step is to generate these three model types on the basis of the input data and on the specified cell size. The TRN cell array looks as visualised in Figure 3, left. The centre of each cell is visualised with a green dot. Each cell has its own attribute value not associated with the attribute of the neighbouring cell. The model therefore will appear to have steps and will certainly not seem smooth. With squares representing the attributes it is in other words not possible to make the seamless transition between the cells that is often desired. Figure 3 TRN Squared Array with primary cells as squares (left). Triangulated TRN on the basis of the squared cell model (right) Each cell is therefore sub-divided into four triangles as it appears in Figure 3, right. The corners of each cell (visualised with a yellow dot) is given an attribute value that is representing the attribute values of the four neighbouring cells. For an average model, the point will be given the average value of the neighbouring cells, whereas it will be given the maximum and the minimum of the four neighbouring cells for maximum and minimum models respectively. By using triangles it is ensured that each piece of the mosaic surface will fit with its neighbouring pieces since the surface of each triangle is defined by the elevations of the three corner points. With all three corners of each triangle having been assigned an attribute that is linked to the neighbouring points, it is possible to create the desired continuous seamless transition between cells, represented by the triangles, within the model. The TRN-based model types can be used to generate and export gridded values even if the desired cell-size and orientation is not identical to that of the model. The present TRN model type selected can then be regarded a look-up table and the export routine will thus, by sending the XY-values, make NaviModel3 return the associated attribute value from the present TRN model type. The generation of contours is also based on the TRN model. For each depth value related to the contour interval and the depth range of the model, the contour routine will search the model and find places with attribute values equal to the desired contour values. For each contour the points returned will be connected taking the basic requirements to contouring into consideration, such as: Contour lines cannot cross each other Contour lines cannot stop in the middle of the model (unless there are no data available) Contour curves cannot split in two Contour curves cannot follow the top of a ridge or the bottom of a depression EIVA A/S Page 4

5 Interpolation Methods Interpolation is used to predict the values of attributes in areas with no observations available, but within the area covered by observations. Predicting values outside this area is termed extrapolation. When data is abundant, like in connection with areas observed with multi-beam techniques, most interpolation techniques will yield (close to) similar results. When data are sparse, however, like in connection with single-beam surveys, the method for interpolation can be critical. Two different methods for interpolation/extrapolation are supported: Interpolated Average TIN Modelling (which is then both a model type and an interpolation method) Interpolated Models NaviModel3 facilitates the method of performing Interpolated models on the basis of a TRN model. The phrase Interpolated covers the fact that an interpolation is taking place internally in the surveyed areas, whereas extrapolation is taking place beyond these areas. NaviModel3 will, on the basis of primary cells ( cells containing observations), interpolate to the neighbouring cells by utilizing a user-defined search radius. Where primary cells are completely surrounding the secondary point in question, taking the search-circle radius into consideration, the method will result in an interpolated result. Otherwise an extrapolated result will be the outcome. Figure 4 Principle of Interpolation: Extrapolation (left) and Interpolation (right) This is visualised in Figure 4 above. The primary cells are indicated with a green dot, whereas the secondary cell in question is represented by a red dot. Around the secondary cell a circle is drawn with the predefined search radius. This is called the search circle. The routine will search for primary cells in all directions inside the search circle. If more than one primary cell is found in a given direction, only the closest will be used to determine the attribute of the secondary cell. Once all directions have been investigated and at least one primary cell has been found inside the circle, the value for the secondary cell in question is found as a weighed average of the attributes of the primary cells found. This weighing is performed as the inverse to the square of the distance between each of the primary cells and the secondary cell in question. The attribute value of the secondary cell is in other words calculated as: As = attribute value of secondary cell n 1 1, with As * * Ap Ap n 2 i 1 i = attribute value of primary cell i i 1 di ) n = number of primary cells found 2 i 1 di d i = distance from secondary cell to primary cell i EIVA A/S Page 5

6 The first part of the equation is used to normalise the result for the attribute of the secondary cell, whereas the second part constitutes the weighing of the observations relative to the inverse of the square of the distances. The method can be considered a dedicated case of the Inverse Distance Weighing (IDW) method that by some is considered the workhorse of spatial interpolation. IDW achieves the desired objective of creating a smooth surface whose value at any point is more like the values at nearby points than the values at distant points. The method is thereby taking Tobler s first law of geography into consideration Everything is related to everything else, but near things are more related than those far apart. IDW is often described as an exact method of interpolation, since the results are true to the input as opposed to an approximate method that allows the result to deviate from the input in the interest of perhaps a higher degree of smoothness of the model. Consider however, if it was really used to try to change the value of a primary cell: the method would then actually arrive at the input value of the primary cell, because the weight would be infinite with a zero distance. The IDW method is considered particularly useful with hydrographic survey data. A weighed average that is never negative will always return a value that is between the limits of the measured values. This means that the method will never generate new undesired highs or lows, not even when extrapolating from the outer skirts of the model. Interpolated models are particularly useful with multi-beam surveys but can also successfully be used with single-beam data. 5. Cleaning Methods Cleaning can take place within the framework of NaviModel3 due to the fact that the raw observations are inherent in the DTM. A series of different cleaning methods are implemented, primarily: Point Edit 3D Cleaning Histogram Plane Cleaning In addition to the two primary built-in cleaning methods, NaviModel3 facilitates the inclusion of dedicated cleaning tools, termed plug-ins. A plug-in tool is here defined as an executable file that reads a point-based data-set and writes back the (edited) result to the same file and consequently back to NaviModel3, once the dedicated cleaning has taken place. Of particular interest in the present context is the S-CAN automatic cleaning plug-in. Point Edit 3D Cleaning The Point Edit 3D cleaning tool is a conventional manual editing tool that was originally developed to be used in EIVAs editing software, NaviEdit. Here it is primarily used on a file-to-file basis. The 3D-based cleaning, in which the user can see portions of the model area includes some manual cleaning and visualization tools. The user is given the possibility, on the basis of the 3D-view, to perform manual cleaning of areas as well as of single points. The clipping plane feature, through which the user can limit the view of the data to an area between two planes, is thought to be particularly useful in connection with pipe data cleaning. The user can thereby edit data in front of and behind an object (pipe) without removing the actual object of interest. It is furthermore possible to show deleted points superimposed on the accepted ones. This includes points deleted in previous cleanings sessions. Once the cleaning is accomplished, the DTM is updated in accordance with the revised information. EIVA A/S Page 6

7 Figure 5 Point Edit 3D cleaning Histogram Plane Cleaning The Histogram Plane Cleaning method is a semi-automatic cleaning tool that, on the basis of a user-defined polygon, will generate a least squares adjusted plane through the corners of the polygon. The tool uses the plane for the subsequent cleaning. The user is given a deletion/selection tool as shown below in Figure 6. The selection tool is an XY-window that in the X-direction shows the distance to the plane, whereas the Y-axis shows number of points. As a guide, proposed maximum and minimum values are visualized with red vertical lines. These lines can be moved forth and back, on top of the distribution curve (histogram), by manual selection and movements of the cursor. Figure 6 Plane Distance selection tool (left) and 3D visualization Another important visual selection guide is given in the 3D window where the consequence of the selection can be monitored, with red dots indicating points to be deleted below as well as above the plane. When accepting the settings, the DTM is promptly updated. The S-CAN Automatic Cleaning Method NaviModel3 supports incorporation of dedicated, user-developed plug-ins for cleaning and antinoise determination. The S-CAN (SCALGO Combinatorial Anti Noise) cleaning tool is such a plug-in, developed in close corporation with the Center for Massive Data Algorithms (MADALGO) at the University of Aarhus. The development of the tool focused on automatic cleaning of the massive multi-beam point-clouds, typically associated with pipe line surveys. In short, the S-CAN algorithm calculates an initial so- EIVA A/S Page 7

8 called Noise Score for each data point in the data-set, and the user can then easily and interactively clean parts of (or the whole) dataset by selecting a region of the data and remove points with high noise scores. Alternatively the user is given the opportunity to use a more differentiated approach to the selection of points to delete. The score value of each sounding is determined or indexed in an initial, relatively processing-heavy, step. The subsequent step of selecting areas with different and dedicated threshold values is developed for efficiency. Here manual intervention is required. The S-CAN is capable of efficiently processing massive datasets that do not match the limitations of internal memory but must reside on disk. The constant movement of data to and from disc during the cleaning is not a performance bottleneck and the algorithm can therefore be regarded I/Oefficient. This is ideal in a NaviModel3 environment, since this is exactly the way data is organised, through the governing Quad Tree principle. The S-CAN plug-in comes in two different variants: a) the Score variant and b) the Components variant. The Components Variant The Components variant separates input observations into series of observations that fulfil an internal requirement regarding maximum tolerable height difference (threshold) between neighbouring points. These neighbouring series are termed surfaces. The minimum height difference between points in a surface and the neighbours in adjacent surfaces is consequently higher than the threshold. Similarly, a large threshold separates into surfaces with high internal difference/noise, whereas a small threshold will divide the observation material into more surfaces as visualised in Figure 7. Figure 7 Principle of the Components variant The largest surfaces, in terms of population, are listed, in sequence, in the user interface, as shown in Figure 9. The user is thereby given an opportunity to choose which ones to keep, as shown to the right in the figure. If the initial threshold is not acceptable for the cleaning, a new score indexing, with a revised threshold, must take place. EIVA A/S Page 8

9 Figure 8 The user interface of the 'Components variant, with the Surface selection window The Score Variant Compared to Components, the Score variant calculates for all thresholds once and for all. This optimizes the testing of the best possible threshold value for a given area and it furthermore honours the fact that different areas might ideally be the subject to different threshold values. In the latter situation, the user will have to perform the subsequent cleaning selection for each of these areas. Figure 9 Principle of the Score variant Figure 10 The user interface of the 'Score' variant, with the Threshold selection window EIVA A/S Page 9

10 Even though the Score variant, as a consequence, is substantially faster than the Components variant, it can only be used in situations where one surface must be determined. A pipe and a seabed can in many instances be regarded one surface. This is actually the case in the examples given here. Similarly, Components should be used when there is a larger variety in the seabed features. Most often however, combining the two variants will be an ideal solution, with Score being used as priority 1, because of its effectiveness, and Components used in the remaining, more complex areas. Compared to other automatic cleaning algorithms commonly used today (usually TPE or CUBE variants), S-CAN does not take the conditions during acquisition, such as the characteristics of each instrument and the overall geometry of the setup, into account. It is therefore not possible to make estimates of the theoretical accuracy of each observation point and thereby use those as basis for the cleaning. The method employed in S-CAN, where only the actually observed data are used as the basis for cleaning, has however proven to be capable of efficiently separating noise clusters from points on top of physical objects like pipelines. 6. The Pipe Object For a pipeline inspection post-processing task, the most important topping (topping items placed on top of the DTM) is the pipe object. NaviModel3 can utilize a combination of three different data types to generate this object: Digitized pipe information Pipetracker data Runline data When determining the pipe the digitized pipe information available is always given first priority. If no digitized pipe information is available, NaviModel3 will look for and use pipetracker data. As third priority, and only in situations where no digitized pipe or pipetracker data is available, the runline information will be used to generate the pipe object. The pipetracker information has typically been exported from NaviEdit after having been edited. When loaded, it will appear in the DTM window, together with a Kalman filter line. This line is based on the pipetracker observations as well as on the Kalman-pipe settings. These settings define the maximum tolerable flexion of the pipe as a function of the pipe diameter. If selected by the user, the Kalman line is used to place the pipe at a later stage of the process. Alternatively the pipetracker data will be used directly. Figure 11 Pipe tracker data with Kalman line, DTM (left) and KP-axis window (right) Digitization of a pipeline is particularly useful in connection with exposed pipes. The digitization can be performed automatically, with the Autoplacing of Pipe functionality, or it can be done manually. To manually generate a digitized pipe object, the user must click in an appropriate position with the mouse for each segment of the digitized pipe. To assist in the digitization, the EIVA A/S Page 10

11 relative range and bearing from the previous point to the present position of the cursor will be visualised as shown below. Figure 12 Digitizing the pipe using snap (blue spheres) and video-lock (in the 3 integrated video windows at the bottom) functions To further assist in the digitization process, the snap and video lock options can be used. As shown in Figure 12, snap will give a set of blue spheres to the left and to the right of the cursor during the digitizing. The point of digitization will appear at the highest position ( top of pipe) as long as the cursor is within the Snap window width. The snap functionality is particularly useful in connection with well-defined, relatively large exposed pipes (or cables). The video-lock functionality is used to force the video to the present position of the cursor and thereby of the digitized line, in order to supply additional visual information for the determination of the whereabouts of the pipe. The next step is to generate the pipe. This is done on the basis of the residing information, with the predefined priority of data, defined above: a) digitized pipe, b) pipetracker data and c) runline data. Once the pipe object is generated, different visualizations with colour-coding of the pipe-status can be used for evaluation purposes, such as: Pipe-flexion status (below left) Pipe burial status(below right) EIVA A/S Page 11

12 Typically the side-flags, based on the pipe-object, will be produced next. Once the flags have been generated, they will be visualized in the DTM window. Based on the depth of the flags, relative to the TOP and to the diameter of the pipe, the KP-axis window will also be updated with the following information: a) free-spans, b) exposures, c) coverages and d) possible burial errors. Figure 13 Side-flags in the DTM-window (left) and in the KP-axis window (right) The final step will be to export information associated with the pipe object for subsequent reporting and documentation. For this a series of exporting functionalities are offered, predefined as well as generic. 7. Offline Eventing The task of generating offline events as part of a pipeline inspection post-processing task is divided in two: Editing, verification and modification of online events Generating new additional (offline) events For this the NaviEvent tool is employed. NaviEvent is an eventing package that can be used with online as well as with offline application. It includes facilitates for editing, in the integrated EventEdit tool, and for generating events. For the latter, NaviModel3 will output the current position of the DTM-window. This information is subsequently used to define the event position in NaviEvent. The trick is therefore to lock this position to the position of the ROV-object, which in turn is identical to the position visualized in the Video-window. When the link between NaviEvent and NaviModel3 has been established, offline eventing can take place. This is initiated by moving the ROV to an appropriate position on the track. The playback of the video can now be started. The situation that, unless intervened by the user, resembles online eventing, is visualised in Figure 14, with the NaviEvent window at the top right and the EventEdit window at the bottom right of the figure. Since NaviModel3 facilitates stepping forth and back in the video data as well as pausing and changing the progress speed, the user is given the option to actually still-position the ROV/video very accurately on top of what appears to require eventing and then perform this. It is apparent that this kind of eventing has an increased the accuracy compared to events performed on the fly, but it also has to be considered slightly more time-consuming. Even though the scenario described in the above associates offline eventing rigorously with the video information, offline eventing can also be performed without any video records available. EIVA A/S Page 12

13 Figure 14 The offline eventing user interface with the NaviEvent window top right and the EventEdit window bottom right 8. Conclusions For the optimization of the post-processing environment within NaviModel3, a series of new features have been implemented. The main contributor to the visual optimization is indisputably the fact that all data of relevance within NaviModel3 is visualised in an integrated 3D based setting that involves different views, such as the 3D DTM-window and the KP-axis window. Also the fact that video functionalities have been incorporated into the modelling tool adds to an enhanced visual environment. Other aspects of significance are: Implementation of an off-line eventing tool that also includes editing of online events Multiple DTMs can be contained and visualised simultaneously Comprehensive visualization tools associated with the pipe as well as with other objects Jointly these visual enhancements provide tools to the users, that facilitate the production of improved and more unambiguous pipeline inspection related data. The speed-optimization and automation of the post-processing task has been concentrated on the initial, processing-heavy fields, with a series of focal points. With pipe-line inspection to a large extent relying on reliable and accurate seabed information, some kind of efficient cleaning of the seabed scanning data is considered a necessity. The cleaning of the multi-beam data has furthermore increasingly become a topic where reliable automation is required. As a consequence of this, a series of cleaning tools, manual as well as automatic, has been implemented. For obvious reasons, the automatic cleaning tools, the S-CAN variants, are the main contributors to the potential speed increase, for the most part because they require a moderate user involvement. With the tools being relatively simple to use, they can furthermore be regarded practically efficient. Having said this, however, in some situations the manual and the semi-automatic cleaning tools will, most often in combination with the automatic cleaning tools, provide optimum solutions. EIVA A/S Page 13

14 Also the fact that NaviModel3 has an unlimited model-size, as a response to the vast increase in data amounts over the last years, contributes noticeably to the speed-optimisation. The implementation of a Quad Tree data structure has resulted in an improved I/O efficiency, so that even though the data is residing on a larger and slower secondary storage device, as opposed to having been loaded into the internal memory, the speed of moving data to and from disc has not become a performance bottleneck, not even in connection with the automatic cleaning sessions. 9. References 1. Pipeline Inspection Tutorial with NaviModel3, EIVA A/S, 2010: 2. User s Manual, EIVA Offline Eventing Tool, EIVA A/S, 2009: 3. Cleaning Massive Sonar Point Clouds, L. Arge, K. G. Larsen, T. Mølhave and F. v. Walderveen, Anti-noise plugin for NaviModel3, EIVA A/S, Press release at Hydro International: 5. Release of NaviModel3 DTM Software, EIVA A/S, Press release at Hydro International: EIVA A/S Page 14