CA2901308A1

CA2901308A1 - Oil and gas infrastructure asset traceability techniques

Info

Publication number: CA2901308A1
Application number: CA2901308A
Authority: CA
Inventors: Lance FUGATE; Elias Gedamu; Jonathan Paul Harrison
Original assignee: VINTRI TECHNOLOGIES Inc
Current assignee: VINTRI TECHNOLOGIES Inc
Priority date: 2012-02-17
Filing date: 2013-02-18
Publication date: 2013-08-22
Also published as: WO2013120209A1

Abstract

A system for tracking and managing oil and gas infrastructure assets comprises a central database. An identification tag, such as a barcode or RFID for example, is mounted on each asset and stores an identifier. Manufacture information is received from a manufacturer data source and validated against data integrity rules to promote data accuracy in the central database. Further, history information is collected from a plurality of entities, during a lifecycle of the asset. For a given asset, the central host database associates the validated manufacture information and the history information to a unique identifier corresponding to the identifier stored in the identification tag of the corresponding asset. A reporting engine is in communication with the central database and provides accessibility to remote devices, for tracking and managing the asset, from the remote device, based on the manufacture information and the history information.

Description

OIL AND GAS INFRASTRUCTURE ASSET TRACEABILITY TECHNIQUES
Field of the invention:
The present invention relates to the field of oil and gas infrastructure asset traceability. More particularly, the present invention relates to infrastructure asset traceability systems and methods for tracing oil and gas infrastructure assets, such as pipeline assets.
Background of the invention:
Assets in the oil and gas industries include various components and materials used for building oil and gas infrastructure, including pipelines.
Assets for building such infrastructures are manufactured and channelled through different facilities for processing, storage, installation, etc. It is desirable to identify and obtain history information on such assets.
Today, the industry accepts information the manufacturers are able to provide and in many cases, poor quality data as the standard.
The manufacturing sector, in general, has manually recorded information and invests minimally in information technology systems and infrastructure. Due to the practice of hand recording manufacturing data, data is prone to errors and the information provided to operators is typically limited to what is required for industry regulatory compliance, rather than the information the operator requires.
On the operator's side, data is, in most cases, in paper copy or spreadsheet form and is not easily shared corporate-wide.
Furthermore, governments and regulators historically have defined compliance practices and not defined how operators must maintain records or information to meet the regulators' compliance standards. With the movement of skilled resources in the industry, few operators are easily able to piece together the historic information of an

2 asset or group of assets to respond to regulator audits without committing substantial effort and resources. The process is time consuming and arduous today due to the lack of integrated and proactive systems.
In the particular case of pipelines, the assets to be tracked include pipe sections which are assembled to construct the arteries of the pipelines. Pipelines are structures for transporting gases, liquids or multiphase mixtures such as slurries.
Pipelines may transport fluids such as oils, natural gas, fuels and other fluids, as well as suspension and slurry type materials.
The main components of a pipeline are the pipe sections which are first manufactured at a fabrication plant. After a pipe section is made, it is typically subjected to testing in order to confirm or validate various desirable or required characteristics related to the metallurgy or the geometry of the pipe section. For instance, a pipe section may be tested for characteristics such as roundness, stress and compression resistance, etc.
In some cases, a sample from a pipe section may be removed in order to test the metallurgy.
Once the testing is complete, a batch of manufactured pipe sections may be sent for post-manufacture treatment. The manufactured pipes may be stacked and stored outside for days or several months before the post-manufacture treatment is undertaken, depending on inventories and demand for the pipes.
Pipe sections manufactured for certain applications are subjected to a post-manufacture coating treatment in a coating plant. The pipe sections may be coated with a polymer layer at a coating plant. The coating may be necessary for the given end use of the pipe (for example, a pipe serving as a segment of a pipeline may remain in one place for about 30 to 50 years and must be coated to prevent premature corrosion, etc.) or for protecting the pipe from external elements during storage. The coated pipe is then shipped for deployment or stored for a period of time before deployment.

3 Ensuring traceability of pipe sections through manufacture, coating and deployment has several challenges. According to current practice, information pertaining to the characteristics of each manufactured pipe section is provided on the pipe section in a manual fashion via a hand applied, industry compliant painted stencil. It is also transferred from one part of the pipe to another from manufacture to deployment, which leads to disadvantages related to inaccuracy, inefficiency and unreliability.
More particularly, at the fabrication plant each pipe section may be assigned a "heat and lot number", which is generally an alpha numeric sequence that is unique to the material of each pipe section. The heat number usually identifies the ingot it came from and the lot number may identify the group of pipe sections that experienced the same heat treatment during the pipe manufacturing process. The manufactured pipe section data typically includes a heat and lot number, and may also include additional codes indicating further characteristics of each pipe section or a batch of pipe sections, such as details on physical properties, composition and manufacturing process conditions. The information regarding the pipe sections is generally stored in a database at the fabrication plant. Other information, such as date, for example, may also be assigned to pipe sections in the database. Current practice is that after the pipe section is made, a labeler manually sprays this information, e.g. the heat and lot number, on the outer surface of the manufactured pipe section.
When the manufactured pipe section arrives at the coating plant or is ready for the coating treatment, the information previously sprayed on the outer surface of the pipe section is copied manually onto the inner surface of the pipe section, prior to the coating treatment. During the transfer to the inside diameter (ID), it is common for manual errors that are a result of misreading the painted stencil information.
The coating process generally involves various treatments including heating, sandblasting and acid washing the outer surface of the pipe before it is coated with an application specific coating (for example, Fusion Bond Epoxy, Abrasion Resistant Coating, Yellow Jacket, etc.). Some of the preliminary treatments, such as

4 sandblasting the external surface of the pipe, are done to prepare the outer surface by removing an outer layer of rust and/or adding texture to increase adhesion of the coating to be applied. Due to this relatively harsh treatment of the external surface of the pipe sections, the pipe specific information (including pipe ID, heat and lot number, etc.) must be copied onto the inside of the pipe prior to the coating process.
Otherwise, the traceability information would be lost in the coating treatments.
Once the pipe section has been prepared for coating, the pipe is slowly heated by induction, typically up to about 250t for example, which corresponds to the coating temperature. The coating temperature may depend on the coating process parameters and the plastic material used for coating the pipe. The coating material is initially provided in the form of plastic pellets. In order to apply the coating, the pipe is fed through a cylindrical opening and, as the pipe is channeled through this cylinder, adjacent plastic pellets are heated to an application temperature, for instance about 500cC, and melt around the channeled pipe, to form a plastic web surrounding the pipe. Pipe sections are fed end to end through this plastic coating cylinder.
The pipe section is then cooled down though a quenching process in which water is sprayed onto the pipe. After the quenching, plastic coating material is removed from extremities of the pipe sections that will be joints when the pipes are deployed. In order to clean the interior of the pipe, water is blown into the pipe and an air gun is then directed through the interior of the pipe to remove the residual water.
After the coating is complete, the information (e.g. heat and lot number) which was re-printed onto an interior surface of the pipe is again manually copied and rewritten on the outer coated surface of the pipe. This procedure of copying and re-writing the pipe information leaves room for various errors including inaccurate replication of the information, poor handwriting, and so on. The information is further entered into the coating plant's database, via a computer which is generally located remotely from the pipe, which may further increase risks of error of the data entered into the database.

When the pipe is deployed in the field or at any intermediate step prior to deployment, the identification information appearing on the coated pipe is particularly useful for tracing the pipe's origin or the intermediate steps or treatments it has been subjected to. For example, if a defect is found in a given coated pipe, it is desirable to be able to

5 trace it back to its fabrication plant and/or coating plant and to identify other pipes of the same batch or having similar characteristics.
The current practice for managing the tracing information of the pipes is elaborate, time consuming and energy consuming, and tends to lead to inaccuracies in the information appearing on the pipe as well as in databases. Indeed, errors can occur in the transcription steps before and after the coating, as well as in the manual re-entry of the information to a remote computer at the coating plant. Moreover, possible smudging or erasing of the information on the pipe's surfaces after manufacturing can tend to distort the information that can be read from the pipe. For example, when pipes are stacked for storage and/or otherwise handled or exposed to the elements, the printed information may be erased due to friction, pressure or movement between the pipes, time factor, and so on.
Hence, in light of the aforementioned, there is a need for a technology that would be able to overcome at least some of the disadvantages of known techniques.
Summary of the invention:
An object of the present invention is to provide a system and a method that respond to at least some of the above-mentioned needs and thus provide an improvement over other known asset tracking systems and methods.
In accordance with the present invention, the above mentioned object is achieved, as will be easily understood, by a system and/or method for tracking and managing oil and gas infrastructure assets such as briefly described herein and such as the one exemplified in the accompanying drawings.

6 In accordance with an aspect of the present invention, there is provided a system for tracking and managing oil and gas infrastructure assets, an identification tag being mounted on each asset and storing a unique identifier. The system comprises a data importation module, integrated in a processor and configured to communicate with a manufacturer data source, for receiving manufacture information related to one of the assets from the manufacturer data source. The data importation module comprises a validation module for validating the manufacture information based on data integrity rules stored in a memory. The data importation module is further configured to receive history information related to the asset from a plurality of entities, during a lifecycle of the asset. The system further comprises a central database being in communication with the data importation module, for storing the manufacture information having been validated and the history information, and for associating the manufacture information and history information with the unique identifier.
The system further comprises a reporting engine, integrated in the processor and being in communication with the central database, to report information from the central database on a user-interface of a remote device, for tracking and managing the asset, from the remote device, based on the manufacture information and the history information.
In accordance with another aspect of the present invention, there is provided a method for tracking and managing oil and gas infrastructure assets. The method comprises importing into a central database manufacture information on a given asset from a manufacturer data source. The importing step comprises validating the data to be imported based on data integrity rules. The method further comprises associating in the central database, the manufacture information having been imported, to a unique identifier stored in an identification tag mounted on the asset. The method further comprises storing in the central database, history information from a plurality of entities, during a lifecycle of the asset after manufacture and associating the history information to the unique identifier, in order to report information from the central database on a user-interface of a remote device.

7 Various objects, aspects, advantages and features of the present invention will become more apparent upon reading of the following non-restrictive description of embodiments thereof, given for the purpose of exemplification only, with reference to the accompanying drawings.
Brief description of the drawings:
FIG. 1 is a block diagram showing a system for tracking and managing oil and gas infrastructure assets.
FIG. 2 is a schematic diagram showing broadly the interactions between a central database, and operators, regulators and manufacturers.
FIG. 3 is a schematic diagram showing broad features of the overall system.
FIG. 4 is a schematic diagram showing the functional features which interact with an oil and gas asset traceability system.
FIG. 5A to 5C show a flow chart illustrating steps carried out by an oil and gas asset traceability system.
FIG. 6 is a diagram of a traceability process map.
FIG. 7 is a block diagram showing a tagging process.
FIG. 8 is a block diagram showing a steel supplier data input process.
FIG. 9 is a block diagram showing a manufacturing data input process.
FIG. 10 is a block diagram showing a coating data input process.
FIG. 11 is a block diagram showing an asset location data update process.
FIG. 12 is a block diagram showing an asset installation data update process.
FIG. 13 is a diagram of an asset management process map.

8 FIG. 14 is a diagram of an enterprise reporting process map.
FIG. 15 is a schematic diagram showing a radio frequency identification (RFID) tag.
FIG. 16 is a schematic diagram showing a validation procedure in relation to the RFID
tag shown in FIG. 15.
FIG. 17 is a schematic diagram showing a storage yard, the storage yard comprising components related to an asset location data update process.
FIG. 18 is a block diagram of an asset traceability system and method.
FIG. 19 is a block diagram showing additional steps of the method according to the bloc diagram shown in FIG 18.
FIG. 20A to 20C are schematic diagram showing steps of a method.
FIG. 21A to 21C is schematic diagram of a tag, the diagram showing a top plan view (FIG. 21A), an upper cross-sectional view (FIG. 21B) and a side cross-sectional view (FIG. 21C) of the tag.
FIG. 22A to 22C are schematic diagrams showing different examples of secondary adhesives for a tag.
FIG. 23 is a block diagram of another asset traceability system.
FIG. 24A is a schematic diagram of a tripod spreader as a first securing means.
FIG. 24B shows the tripod spreader of FIG. 24A mounted in a pipe.
FIG. 25A is a schematic diagram of a bar spreader as a first securing means.
FIG. 25B shows the bar spreader of FIG. 25A mounted in a pipe.

9 FIG. 26A is a schematic diagram of a wire spreader as a first securing means, according to an embodiment of the present invention, the wire spreader being shown in a neutral configuration.
FIG. 26B shows the wire spreader of FIG. 26A in an operative configuration.
FIG. 26C shows the wire spreader of FIG. 26A in an operative configuration, mounted in a pipe.
FIG. 27A is a schematic diagram of a custom spreader as a first securing means, the diagram showing a top plan view (FIG. 27A), a side plan view (FIG. 27B) and an elevational view (FIG. 27C) of the custom spreader.
FIG. 27D is a cross-sectional view of two pipes, each having the custom spreader of FIG. 27A to 27C mounted therein, the two custom spreaders being joined by a plug.
The plug also prevents the pipes from colliding with each other damaging the bevel.
FIG. 28 is a schematic representation of a drilling pipe.
FIG. 29 is a block diagram of another asset traceability system and method.
Detailed description:
In the following description, the same numerical references refer to similar elements.
The embodiments mentioned and/or geometrical configurations and dimensions shown in the figures or described in the present description are embodiments of the present invention only, given for exemplification purposes only.
Broadly described, the asset traceability system according to an embodiment of the present invention, as exemplified in the accompanying drawings, provides a central management of traceability data related to the manufacturing and the lifecycle of an asset, data integrity controls to promote data accuracy, and distributed access to the data in order to meet the individual requirements of operators, regulators and manufacturers.

System and method for tracking and managing oil and gas infrastructure assets Referring to FIG. 1, an embodiment of a system 1000 for tracking and managing oil and gas infrastructure assets 105 is illustrated. An asset 105 may be for example a pipe section 106 (see FIG. 16), or another asset such as a fitting, a valve, and/or any 5 other component used in the construction and maintenance of oil and gas infrastructure. An identification tag 108 such as a barcode or a radio frequency identification (RFID) tag is mounted on the asset 105. Alternatively, the identification tag may be provided in the form of a magnetic stripe tag, a tag comprising any suitable electronic chip and/or the like. Preferably, the identification tags 108 are pre-

10 made, each storing a unique identifier 109, in order to reference the asset 105 on which it is mounted, in a database. In some cases, an identification tag 108 to be mounted on an asset may be generated by a tag printer 1036, as will be explained further below.
By "mounted", it is meant placed, fixed, secured, fastened, attached, adhered, and/or the like. Some optional ways of mounting certain types of tags will be discussed further below.
Referring to FIG. 1, the system 1000 comprises a data importation module 1012, integrated in a processor 1014 and configured to communicate with a manufacturer data source 1016. The data importation module 1012 receives manufacture information 1018 related to assets 105 from the manufacturer data source 1016 and validates the manufacture information 1018 based on predefined data integrity rules 1020 stored in a memory 1022. The data integrity rules 1020 are preferably defined in compliance with operator's requirements, regulatory requirements, and/or the like.
For example, the manufacturer information 1018 may be received, in the case of pipe sections, from a steel manufacturer 302, from a pipe mill 312, and/or from a coating plant 322 (see FIG. 5A).

11 Referring back to FIG. 1, the data importation module 1012 is further configured to receive history information 1023 related to the asset 105 from a plurality of entities 1025. Such entities 1025 may include, in the case of pipe sections for example, a transportation system 332, a storage yard 342, a construction yard 352, a pipe cutting facility 362, a surveyor 372, an installation facility 382, an operations and maintenance facility (see FIG 5A, 5B, 5C), etc., during a lifecycle of the asset. The installation data source may include: welding data; x-ray data; pipe cutting data; pipe bend data; coating data; girth weld coating data; pre-commissioning test data;
and/or inspection data. The operations and maintenance data source may include:
inline inspection data; cathodic protection data; pipe quality data; visual inspections; and cut-out and replacement data.
The data importation module 1012 may further comprise a data input module 1015 for identifying a format of the manufacturer information 1018 received and for reading the manufacturer information 1018 based on the format, as will be described further below with reference to FIG. 8.
The data importation module 1012 may further comprise a data parser 1193 for identifying a correspondence between the manufacturer information 1018 to be imported and fields of the central database 126, as will be described further below with reference to FIG. 9.
The system 1000 further comprises a central host database 126 being in communication with the data importation module 1012. The central host database 126 stores the manufacture information 1018 having been validated and the history information 1023, and further associates the manufacture information 1018 and history information 1023 representing an asset 105 with the unique identifier 109.
It is to be understood that the database preferably comprises a series of records, each record being referenced to an asset's unique identifier 109 using a reference field. The reference field may contain the unique identifier 109 or it may contain other data which is associated to the unique identifier 109. For example, the content of the

12 reference field may append characters to the unique identifier 109, or it may result from a manipulation of the unique identifier 109. For example, "123-xyz" in the reference field of the database could be associated to unique identifier 109:
"xyz" of manufacturer "123". In another example, "AAA" in the reference field of the database could be associated to unique identifier 109: "111", where the manipulation consists in converting the character "A" into digit "1". In yet another example, "YYYY-MM-DD
xyz" could be associated to the unique identifier 109 "xyz".
Thus, it is to be understood, in accordance with some embodiments, that the unique identifier 109 may be combined with additional information and/or further processed to correlate with the content of the corresponding reference field, as may be readily understood by a skilled person. Thus it should be understood that though the identifier 109 may be unique within a given group of tags 108, the content of the reference field of each record identifies one particular asset 105 only, within the database.
Furthermore, while each asset may have a single corresponding tag and identifier, it is to be understood that multiple tags may be associated to the asset, as several of the manufacturing facilities 1016 may provide the asset with their respective identification tags, provided each tag stores an identifier which is unique in the central database. For each tag having a new unique identifier for an asset being associated to another unique identifier in the database, this new unique identifier is stored in the database in association the previously stored unique identifier. Therefore, one given asset may be associated to a plurality of unique identifiers.
Referring back to FIG. 1, the system 1000 further comprises a reporting engine 1024.
The reporting engine 1024 is integrated in the processor 1014 and in communication with the central database 126, in order to report information from the central database 126 on a user-interface 1029 of a remote device 1028, so as to track and manage the asset 105, from the remote device 1026, based on the manufacture information and on the history information 1023. The reporting engine 1024 may be configured to

13 provide a real-time accessibility to remote devices 1026 via a communication network 128, for tracking and managing the asset. The remote devices 1026 are further in communication with the database 126 via the communication network 128.
The reporting engine 1024 may further comprise a data retrieval module 1027 for retrieving information from the database 126 on the basis of a given unique identifier 109 stored on an identification tag 108 of an asset 105. The reporting engine may further comprise an output module 1029 for outputting the report to one of the remote devices 1026 via the communication network 128.
In the context of the present description, the term "processor" refers to an electronic circuitry capable of executing computer-readable instructions, such as a central processing unit (CPU), a microprocessor, a controller, and/or the like. It is to be understood that the processor 1014 described and illustrated herein may be provided by a plurality of such processors which cooperate, either independently or within a distributed system, as can be understood by a skilled person. For example, the reporting engine 1024 and the data importation module 1012 may each be provided in a separate processor. Moreover, the reporting engine 1024 and the data importation module 1012 may each be provided in a plurality of such processors. The processor 1014 may be provided within one or more general purpose computer, for example, and/or any other suitable computing device.
In the context of the present description, the term "network" refers to any suitable communication system for transmitting data, and may include a local area network (LAN) or the like, a wide area network (WAN), a global area network (GAN), the Internet, etc., and may be provided by wired or wireless technologies.
Wireless technologies may use, for example, microwave, radio, infrared communication technologies and/or the like.
The remote devices 1026 may include a ruggedized laptop computer 1028, a tablet computer 1030, a smart phone 1032, a hand-held computer device, and/or any other suitable computer device 1034 enabled to provide a web browser application.
The

14 communication network 128 (also referred to herein as "network connection"), may be an Ethernet, WiFi, 3G, 4G, connection and/or any other suitable communication network.
It is to be understood that the system 1000 may be adapted to operate in a client-server architecture, where the database 126 is comprised in a server 124 (see FIG. 18) and the remote devices 1026 are client devices. Preferably, each remote device comprises a client application (for example, an internet browser or the like, and/or a dedicated application stored on the remote device). It is to be understood that the client application, may operate differently (for example, in terms of display format, accessible data for reading, accessible data for updating, reporting capabilities, functional features of updating the database or only reading from the database, etc.) depending on the particular device 1026, depending on the user permissions and/or role of the user associated to the device 1026 or the user being logged on to the application). For example, a field operator at a given stage of the lifecycle of an asset may access a client application on a particular device 1026 in order to retrieve and/or validate "birth" data relative to one or more assets, while in another example, a regulator personnel may access a client application on another device 1026 in order to retrieve information relative to the lifecycle of given assets, for controlling purposes and/or obtaining statistic information. Thus, the reporting capabilities may be provided in a variety of ways, as can be easily understood by the skilled person, and in view of additional explanations given further below with reference to FIG. 14.
The system 1000 may further comprise a tag reader 122 which is in communication with the database 126 over a communication network 128 for exchanging information with the database 126, the tag reader 122 having a reading module for reading the identifier 109 stored on the tag 108 of each asset 105. The tag reader 122 allows an operator to read the tag 108 and to interact, via one of the devices 1026, with the database 126, by inputting the tag identifier 109. For example, it may be desirable to retrieve manufacture or history information 1018, 1023 related to the asset 105, or to update the database 126 with additional history information 1023, as will be further explained in view of the explanations further below with reference to FIG. 5A, 5B, 5C.
The system 1000 may further comprises an administration module 1013, integrated in the processor 1014, for administering user accounts and associated permissions to 5 access the central database 126. More particularly, the administration module 1013 allows the initialisation of user accounts, managing user permissions, security and/or access to project specific data.
The system 1000 may further comprise a tag printer 1036 for printing a new identification tag 108.
10 A method, which may be executed by the above-mentioned system 1000, may be broadly described as follows with reference to FIG. 1, 5A-5C and 9. A step of the method comprises importing 1180 into a central database 126 manufacture information 1018 on a given asset 105 from a manufacturer data source 1016.
The importing 1180 step comprises validating 1194 the data 1016 to be imported based

15 on data integrity rules 1020. Another step of the method comprises associating 1202 in the central database 126, the manufacture information 1018 having been imported, to a unique identifier 109 stored in an identification tag 108 mounted on the asset 105. Yet another step of the method comprises storing in the central database 126, history information 1023 from a plurality of entities 1025, during a lifecycle of the asset 105 after manufacture and associating the history information 1023 to the unique identifier 109, in order to report information from the central database 126 on a user-interface 1029 of a remote device 1028, for tracking and managing the asset 105, from the remote device 1028, based on the manufacture information 1018 and on the history information 1023. The various steps of the method will be described with further detail hereinbelow.
FIG. 2 broadly illustrates the interactions between the central database 126 and the operators 1040, regulators 1042 and manufacturers 1044.

16 FIG. 3 depicts broad features of the overall system. Namely, the identification of the critical assets 1052 to be tracked and data collection 1054 may be defined based on an organization's requirements and further to a gap analysis 1062 for comparison with best practices. Moreover, data accuracy 1056 and data integrity 1058 are desirable in order to leverage risk management. Data distribution 1060 relates to the accessibility to centralized data from remote locations where the data is desired and also to reporting or the like. A tagging solution 1064 physically identifies assets and reading tools 1066 are used for reading the identification tags mounted on the assets.
FIG. 4 schematically illustrates functional features which may interact with the system 1000, which is shown with the central host database 126. Asset management 1072 broadly encompasses asset tracking 1074, procurement controls 1076, and preventative maintenance 1078. Traceability and reporting system 1080 encompasses engineering specification controls 1082. Engineering specific controls 1082 are specific engineering attributes that an asset must adhere to or fit within the confines of. For example, the wall thickness of a pipe may have to be a minimum thickness. Application interfaces 1084 are provided for interacting between the system 1000 and external systems 1086, such as external control systems, geospatial systems, ERP systems, system integration and/or any other third party system. Application maintenance and releases 1088 also solicit the system 1000.
Custom reporting 1092 is intended to provide real-time field access and reporting 1096, as well as dashboard and data analytics 1094.
The flow charts 300 shown in FIG. 5A, 5B and 5C exemplify broad steps that may be carried out by a pipeline asset traceability system, according to embodiments of the present invention, in relation to different facilities encountered in the lifecycle of pipe sections. Steps 304, 314, 324, 334, 344, 354, 364, 374, 384, 394, are carried out at the sites 302, 312, 322, 332, 342, 352, 362, 372, 382, 392, respectively. The data being processed at the host database 126 for each of the steps is shown at blocs 306, 316, 326, 336, 346, 356, 366, 376, 386, 396, respectively. Moreover, value chain details 308, 318, 328, 338, 348, 358, 368, 378, 388, 398, and design considerations

17 310, 320, 330, 340, 350, 360, 370, 380, 390, 400 are further detailed for each of the steps.
The previously-mentioned step of importing 1180 (see FIG. 9) the manufacture information 1018 comprises importing steel manufacturer information 306 from a steel manufacturer 302. At the steel manufacturer 302, a steel manufacturer tag 304 is applied onto the coil or slab for tracking a Mill Test Report (MTR) data capture. A
feedback loop is executed in order to signal when coils are received (310), and to trigger data capture (310). At 306, the following information is imported into the central host database 126, and associated to a corresponding record containing the identifier 109 of the tag 304: origin details, metallurgy data and MTR data.
This data capture advantageously allows inventory location tracking (308).
The step of importing 1180 (see FIG. 9) the manufacture information 1018 further comprises importing pipe mill information 316 from a pipe mill 312. At the pipe mill 312, a pipe mill identification tag 314 is applied for tracking and "birth"
data capture.
More particularly, a unique identifier is assigned to each pipe section in the central host database 126. The asset is thus associated in the central database 126 with a new unique identifier stored on a corresponding pipe mill identification tag mounted on the asset 105 at the pipe mill. At 316, the following data is stored in association with this unique identifier 109 in the central host database 126:
Tally data;
Mill Run data; Inspection Result data; and Work Order integration data. In the importation of the pipe mill data, an automated and/or enforced error and exception tracking is applied (320), in order to promote data integrity within the database 126.
This improves traceability, reduces returning articles unnecessarily, and improves data integrity through digital data capture (318).
The pipe is then transferred to a coating plant 322. The step of importing 1180 (see FIG. 9) the manufacture information 1018 thus comprises coating plan information 326 from a coating plant 322. At this stage, the pipe mill data 316 is verified in order to increase data integrity, and digital data and audit trail captured while manual data

18 entry is avoided (328,330), i.e. the step of validating 1194 (see FIG. 9) further comprises validating the pipe mill information 316 based on the manufacturer data 1018 stored in the database 126. Moreover, additional identification tags are applied to the pipe section for redundancy and coating data capture. The additional tags are in conformity with the coating plant's 322 requirements, and may contain a new unique identifier 109, different from the one stored on the pipe manufacturer tag (314). Indeed, multiple identifiers may reference a same asset in the database 126.
The following coating plant information 326 is imported into the central host database 126: tally data; inspection result data; and coating specification data.
The pipe is then processed for transportation (e.g. via rail car). Thus, one of the entities 1025 of the storing step in the above-mentioned method is a transportation facility 332 and the storing of history information 1023 comprises storing transportation information 336. The following transportation information 336 is imported into the central host database 126, through batch processing: data related to way bills and/or bills of lading; shipper data; tracking sub-contractors; and receiving information. This stage allows inventory management and asset location tracking (338). The batch processing reduces the risk of error, and eliminates manual data entry (340).
The next stage is the storage of the pipe at a storage yard. Thus, one of the entities 1025 of the storing step in the above-mentioned method is a storage facility 342 and the storing of history information 1023 comprises storing storage information 346. At this stage, the shipping and receiving information from the rail car is validated, based on shipping related information being previously stored in the database 126.
Moreover, upon receipt of the asset at the storage yard, the physical location of the asset is updated in the central host database 126. The following storage information 346 is imported into the central host database 126 through batch separation and/or three-way matching in the enterprise resource planning (ERP) system of the storage yard: purchase order (PO) number; and vender identification, in order to synchronize

19 the data from the database 126 with the ERP of the storage yard. This stage provides inventory management and asset location tracking (348).
The pipe is then eventually transferred to a construction yard. Thus, one of the entities 1025 of the storing step in the above-mentioned method is a construction facility 352 and the storing of history information 1023 comprises storing construction yard information 356. At this stage, the shipping and receiving information is validated (360) against shipping related information being previously stored in the database 126. Indeed, the afore-mentioned method may further comprise storing in the database shipping and receiving information related to the asset 105; and validating 360, at the construction facility, the shipping and receiving information. The following construction yard information 356 is imported into the central host database 126:
material testing reports and location information within the construction yard.
Advantageously, inventory information is updated from the construction yard which reduces the need for re-ordering assets due to logistic errors, thereby reducing waste of assets, returning of asset and write-offs (358).
The following stage may include the cutting of the pipe and/or bending of the pipe.
Thus, one of the entities 1025 of the storing step in the above-mentioned method is a pipe cutting facility 362 or a pipe bending facility and the storing of history information 1023 comprises storing pipe cutting information 366 or pipe bending information. At this stage, the system is solicited for data recording 364. More particularly, the information recorded includes information on bends, joints (single, double, triple); and pipe information is updated and tracked. The following pipe cutting information 366 is stored in the central host database 126: cut and joint related information, X-ray testing data; and child and parent association data. Advantageously, bends and joints information is recorded and the child and parent relationships are tracked (368).
Indeed, when a pipe is cut, one or more child data is generated for each cut section of the pipe and associated to a parent identifier representing the pipe prior to cutting.
Thus, pipe lineage is associated with all child segments of cut pipe, and the imported data is validated against specification drawings mapping the positioning plan in the field (370). The following pipe bending information is further stored in the central host database 126: bending specification information; and structural integrity impact information.
Each pipe section is eventually given an installation location which is mapped by a 5 surveyor. Thus, one of the entities 1025 of the storing step in the above-mentioned method is a surveyor entity 372 and the storing of history information 1023 comprises storing surveyor information 376. At this stage, the surveyor interacts with the system for location data services (374), which update survey mapping information. The following surveyor information 376 is further stored in the central host database 126:
10 pipe latitude, longitude, elevation; and integration with third party mapping services such as GoogleTM, esriTM, BLACKBOXTM. Location data is digitally captured and automatically associated in the database (380). Advantageously, storage information is centralized and integrated (378).
Another stage is the installation of the pipe and maintenance. Thus, one of the 15 entities 1025 of the storing step in the above-mentioned method is an installation facility 382 and the storing of history information 1023 comprises storing installation information 386. The system provides secure access to pipe history information in an organized and real-time dashboard environment (i.e. user interface) for ongoing information (384). The following installation information 386 is further stored in the

20 central host database 126: maintenance data; reporting options data;
depth of buried pipe; preventative quality control measures taken; and maintenance related work information. Moreover, the database 126 may be accessed for reporting.
Referring now to FIG. 6, a traceability process map 1100 is shown according to another embodiment.
The following are preliminary processes 1102 which may be carried out for promoting data integrity of the data stored centrally in the database 126 (see FIG. 1):

21 - every supplier of assets or materials for producing the assets is required to supply manufacturing data to the central host database 126;
- data collection points are required to be configured with an electronic data transfer capability;
- manufacture data and composition material origin information is to be submitted to the system electronically either directly or via a file transfer;
- data to be imported into the database 126 is subjected to integrity rules before approval and storage in the database; and - data integrity standards are defined based on an analysis with the supplier as well as the customer's requirements.
At the steel manufacturer 1104, coil and heat information is electronically submitted to the system 1000 (see FIG. 1) from the manufacturer's data source. The steel supplier data input process and the manufacturing data input process will be explained further below, with reference to FIG. 8 and 9, respectively.
At 1106 an appropriate type of identification tag is selected based on the needs and requirements of the supplier or participant and mechanical requirements. The tagging process will be discussed further below, with reference to FIG. 7.
At the pipe mill 1108, a pipe identifier, corresponding to the identification tag, is assigned in the database 126 and associated with the stored coil and heat information. Pipe manufacturing quality information is also updated in the database 126. The identification tag may be applied after the welding process on the outside diameter.
In the storage yard 1110, the pipe location is updated in the database with rack and row information. As an optional measure, an active tag is assigned to the pipe to provide real-time location in the storage yard, by means of a suitable reading device.

22 The asset location data update process will be discussed further below, with reference to FIG. 11.
At the coating plant 1112, the identification tag is scanned for updating the corresponding record in the database 126. Namely, location information and post-coating information is updated in the database 126. Furthermore, confirmation data is returned, and a permanent tag is applied on the outside diameter of the coated pipe.
The coating data input process will be discussed further below, with reference to FIG.
10.
The pipe arrives at the transportation facility, where the outside diameter tag is scanned to read the identifier and thereby access the corresponding record in the database. The corresponding location information is updated in the database 126.
The asset location data update process will be explained further below, with reference to FIG. 11. Moreover, manifest and way bill information is added to the database, at this stage.
At the construction yard 1116, the tag is scanned, in order to update the location information. The asset installation data update process will be discussed further below, with reference to FIG. 12.
At 1118, the recorded data is then made available via browser or administrator dashboard (i.e. the afore-mentioned client application) for reporting purposes and/or obtaining real-time information for operation.
FIG. 7 illustrates the afore-mentioned tagging process 1120. Broadly, with reference to components shown in FIG. 1, a step 1122 comprises providing the identification tag 108 having the unique identifier 109 stored thereon. Another step 1134 comprises mounting the identification tag 108 on the asset 105. If the tagging process is not completed 1138: (i) a new unique identifier is generated in the database; (ii) a new identification tag having the new unique identifier stored thereon is provided; (iii) the new identification tag is mounted on the asset 108; and (iv) if the tagging process

23 1138 is not completed, steps (i) to (iii) are repeated 1140. As exemplified at FIG. 7, an identification tag is selected 1122 among different types of tags, such as an RFID tag 1124, a bar code with an RFID tag 1126, a barcode 1128, a 2D bar code 1130, and/or any other suitable identification tag 1132, for mounting onto the asset at a given facility. At 1134, a given number of tags are applied to the asset, at a given facility. At 1136, commissioned tags are associated with a unique identifier in the central database 126, using an interrogator 122. If another tag is to be mounted to the asset at 1138, then the process is repeated 1140 until the final tag has been placed on the asset 1142. It is to be understood that steps 1122 to 1134 may be executed for different facilities. For example, a first loop 1140 may be executed at the pipe mill 312 to apply a pipe mill identification tag, and another loop 1140 may be executed at the coating plant 322 to apply a coating plant 322 identification tag, with reference to FIG.
5A.
FIG. 8 illustrates the afore-mentioned steel supplier data input process 1150 for importing steel supplier data into the central host database 126. An identification tag is selected among different types of identification tags 1152 (for example RFID tag 1154, bar code 1156, a bar code with an RFID tag 1158 and/or any other suitable identification tag 1160) for identifying a coil or slab. At 1162, the data associated with the steel (metallurgy, test data, etc.) is collected from the steel suppliers data source.
At 1164, the data input means is determined, via the data input module 1015 (see FIG. 1), based on the input data format for example, a PDF file 1166, an MS
Word file 1168, an image file 1170, and/or any other suitable electronic data transfer format 1172. Under this format, each set of data related to an asset is associated by a unique identifier in the central host database (typically the heat number), at 1174. At 1176, the data is imported into the central database 126. The data is then available as a clickable link on the user interface for accessing the database, at 1178.
FIG. 9 shows the afore-mentioned manufacturing data input process 1180. Data to be imported from the manufacturer data source is first formatted at 1182, for example in a CSV file 1184 or a XLS/XLSX file 1186, or alternatively, a direct database

24 connection 1188 is established. Any other suitable data importation method 1190 may be used, as can be understood. Thus the importing step 1180 of the afore-mentioned method comprises identifying 1182 a format of the manufacturer information received.
At 1192, the data to be imported is then processed through the data parser 1193 (see FIG. 1). More particularly, the importing step 1180 of the afore-mentioned method comprises parsing 1192 the manufacturer information 1018 based on the identified format in order to identify a correspondence between the manufacturer information 1018 to be imported and fields of the central database 126. At 1194, the data to be imported is then verified through data integrity rules. At 1196, if the data conforms to the integrity rules, then it is further processed for storage into the database 126, at 1202. The data integrity rules may be preferably predefined. The data importation module 1012 (see FIG. 1) may further comprise an error processing module 1019 (see FIG. 1) for processing an error output from the validation module 1017 (see FIG.
1).
Examples of data integrity rules may include at least one among: validating that the number of digits in a heat number corresponds to an expected number of digits;

validating that a temperature reading is within a predefined range of temperature;
validating numeric and alphanumeric character requirements in a given pipe number;
validating that a wall thickness or coating thickness falls within a given range; and/or the like. If the data does not conform to one or more of the integration rules, an error report is generated and escalated, according to an escalation process at 1198, and the error is processed to correct the data to be parsed by the data parser 1193 at 1200. As part of the escalation process, an email or other electronic message containing the information to respond to, is sent to an individual identified as being responsible for handling an escalation. A corporate hierarchy may be defined in the error processing module 1019 to manage the escalation process.
Thus, the importing 1180 step (a) of the afore-mentioned method may further comprise after the validating 1194 step: receiving 1196 an error output from the validating step; processing 1198 the error output; and receiving 1200 data correction instructions.
FIG. 10 illustrates the afore-mentioned coating data input process 1204. At 1206, the pipe enters a coating production line. At 1208, if the pipe is provided with a suitable 5 identification tag, the tag is scanned on the inside diameter of the pipe 1210, otherwise a tag is commissioned and placed on the inside of the pipe 1212. The central host database 126 is then accessed at 1214. At 1216, the system determines whether the asset exists in the database 126. If not, the following information is entered in the database 126 at 1218: pipe identifier, heat number and length.
10 Furthermore, an escalation email addressed to an appropriate person is sent out. If the asset does exist in the database 126, then the pipe follows the coating plant process according to 1220. If the coating is not complete, the pipe is further processed for coating at 1220. Once the coating is completed at 1224, the inside diameter tag is removed and a final identification tag is commissioned and applied to 15 the outside diameter of the pipe. At 1226, the database 126 is updated with final status information on the coating of the pipe as well as all events that occurred during the coating process (temperature, coating thickness, deficiencies, etc.). The database 126 is further updated with location information at 1228, as exemplified above with reference to FIG. 5C.
20 FIG. 11 illustrates the afore-mentioned asset location data update process 1230. At 1232, the asset is received on location. At 1234, if the pipe already has a suitable identification tag having been recorded in the central host database 126, then the tag which is located on the outside diameter is scanned at 1240. Otherwise a pipe identification number should be stenciled on the pipe and a tag is commissioned at

25 1236 and paired with the stenciled pipe identification number;
furthermore, the asset is flagged at 1238, as being manually updated and an escalation email addressed to an appropriate person is sent out for verification procedures regarding manually updated assets. At 1242, the asset is updated with current location which may be preprogrammed by the interrogator 122 (see FIG. 1). The database 126 is then

26 updated with the location information at 1244, as exemplified above with reference to FIG. 5C.
FIG. 12 illustrates the afore-mentioned asset installation data update process 1250.
At 1252, the asset is received at the installation location. At 1254, if the pipe already has a suitable identification tag having been recorded in the central host database 126, then the tag which is located on the outside diameter is scanned at 1258.

Otherwise a pipe identification number should be stenciled on the pipe and a tag is commissioned at 1256 and paired with the stenciled pipe identification number;

furthermore, the asset is flagged at 1260, as being manually updated and an escalation email addressed to an appropriate person is sent out for verification procedures regarding manually updated assets. At 1262, the asset follows field specific installation procedures. The database 126 is then updated with the installation information at 1264. Installation information may include weld information, x-ray information, final location coordinates, etc.
FIG. 13 shows an asset management process map, in accordance with an embodiment of the present invention.
The following are preliminary processes 1168 that may be carried out for promoting data integrity of the data stored centrally in the database 126 (see FIG. 1):
- the asset is manufactured, shipped and installed in accordance with the lifecycle process described hereinabove;
- asset information is stored in the database, including location, manufacturing information, metallurgical information; and - asset location is updated as the asset moves along its lifecycle steps.
At 1270, data related to the following operational activities may be exchanged with the central host database 126:

27 - operator tasks;
- operational policies;
- logs;
- metering; and - risk assessment.
At 1272, data related to the following maintenance activities may be exchanged with the central host database 126:
- planning;
- regulatory;
- preventative; and - emergency.
At 1274, data related to the following change management activities may be exchanged with the central host database 126:
- change request and review/approvals;
- associated work orders;
- related work association; and - materials management.
At 1276, the following incident-related data may be exchanged with the central host database 126:
- classification;

28 - related records, other incidents, change requests, etc.
- investigation.
At 1278, the following dashboard-related data may be exchanged with in the central host database 126:
- Highlights exceptions;
- Customization of view based on role/need;
- Pre-formatted fields for easy data entry.
At 1280, the following reports may be pulled from the central host database 126:
- Work schedules;
- Maintenance reports;
- Incident reports;
- Others as defined.
At 1282, the recorded data may then be made available via a browser for obtaining real-time information for operation or via administrator dashboard for reporting purposes.
FIG. 14 illustrates the enterprise reporting process map, in accordance with an embodiment of the present invention.
The system may be configured according to the following specifications (1286):
- access to data stored in the central database 126 is granted through a secure user count system;

29 - user profiles are restricted based on role, business unit and areas of responsibility;
- the ability to add or change or manipulate data is granted based on profiles with all changes being recorded in a change log; and - copies of all uploaded documents are stored inside the database 126; and full history of created and printed report is created and tracked inside the database.
At 1288, the asset in question is identified through the scanning of the identification tag mounted on the asset (RFID tag, bar code, and/or the like), or performing a search on the database, through a user interface application.
Data may be accessed on any internet enabled, browser-based device including computers, tablets, smartphones, and/or the like (1290).
At 1292, a dashboard-type user interface is displayed on a display screen after logging in based on user profile and areas of responsibility and permissions.
Immediate access is provided for commonly used features and works basis.
For traceability reporting 1294, the user can access to assess specific information including metallurgy, manufacturing and coating information.
Regulatory reporting 1296 includes obtaining specific regulatory report through a regulator dashboard (i.e. client application accessed from a remote device for access by regulator personnel).
At the field data level 1298, on-demand reporting is possible directly from the field, preferably with real-time access to the database 126, using a tablet, smartphone or laptop.
Custom reporting and interfaces 1299 are configured to interact with third party systems such as SAPTM, JD EdwardsTM, etc., preferably in real-time.

With further reference to FIG. 1, the afore mentioned method may further comprise:
receiving a reporting request, which was sent from the remote device 1026, the request comprising the unique identifier 109 of the asset 105; retrieving the requested information from the database 126; and returning a report to the remote device 1026, 5 in response to the request, for presentation on the remote device 1026.
The sending step and the retrieving step are preferably executed in real-time. The report comprises at least one of: manufacturer information 1018 and history information 1023 retrieved from the database 126. The reporting request may originate from a workspace accessed via the remote device 1026 based on login information from a 10 user. The login information preferably comprises a user identifier associated to the user, and the accessing step further comprises verifying a user permission based on the user identifier. The retrieving step preferably comprises retrieving the requested information for which the user permission allow access to. The unique identifier 109 of the receiving step may originate from a reading of the identification tag 108 of the 15 asset 105, via a tag reader 122, and/or from a user entry.
Alternatively, the reporting request may comprise a plurality of the unique identifiers 109 associated to a plurality of corresponding one of the assets 105.
Referring now to FIG. 15 and 16, an RFID identification tag 108 to be mounted on a pipe section 106, or other asset 105, is illustrated, for exemplification purposes, in 20 accordance with an embodiment of the present invention. Alternatively, the tag 108 may include any other identification medium, such as a bar code for example.
The tag 108 illustrated in FIG. 15 and 16 comprises a polymer body 1302 encasing an RFID circuit 1304. The polymer body 1302 has a composition which withstands temperatures reaching 300 C, in order to resist the rigors of the manufacturing 25 process and protect the RFID chip 1304.
The body 1302 of tag 108 comprises a mounting surface 1306 which faces the pipe 106 when the tag 108 is mounted thereon, and an outer surface 1308 opposite the mounting surface 1302. A primary stage securing mechanism 123 comprises a magnet 1310 within the body 1302 near the mounting surface 1302 and an adhesive 1312 on the mounting surface 1302, covered by a peel away tape 1314. The magnet 1310 and the adhesive 1312 create a bond with a surface of the pipe 106, such that tag 108 cannot move under an air pressure reaching 1000 psi, to which the pipe may be subjected to during the coating process.
A secondary stage securing mechanism 118 may comprise an adhesive strip 1316 to be placed over the tag 108, onto the outer surface 1308, and extending onto the pipe's surface 1318 by approximately one inch about the tag 108. The adhesive strip 1316 provides increased adhesion surface with the pipe 106, and further prevents the tag 108, which protrudes from the surface of the pipe, from being sheared off.
Thus, prior to the coating process, a tag 108 is temporarily mounted on the inside 116 of the pipe 106, by means of the magnet and adhesive on the mounting surface.
After the coating process, the tag 108 is removed from the inside 116, placed on the outside 120 and the adhesive strip 1316 is adhered over the tag 108 and further to a portion of the pipe's surface 1318 surrounding the tag 108.
According to known methods, pipes are surrounded at each end with a nylon rope to provide a buffer between adjacent pipes when they are stacked, for storage for example. The nylon rope has a thickness of about one inch. Thus, the polymer body 1302 may have a profile which is no thicker than the nylon rope when compressed under the weight of the stacking pipes.
Typically, pipes may be stacked over about 5 levels. Thus, the polymer body 1302 is designed to withstand about 5 tons of weight, to which the pipe may be subjected to during storage, for example when several pipes are stacked.
In a manufacturing example, once a steel pipe is cool enough, the tag may be mounted onto the pipe, and the pipe may be tracked as it is going through the manufacturing process. In an alternative example where the pipe manufacturer does not apply any tags, then the tag may be mounted on the pipe on a first bench of the manufacturing process, that is to say, a pipe coming from a storage yard is put on the first bench, it is cleaned, then warmed up to a specific temperature and then the tag is mounted on the pipe. Then the pipe is subjected to the coating process where the temperature reaches up to 300t.
Referring now to FIG. 17, an asset location feature is schematically illustrated, in the context of a storage yard 1320. More particularly, global positioning system (GPS) devices 1322 are positioned about the storage yard 1320 in order to provide location of stacked pipes 106 by pile. Using an interrogator 122 (see FIG. 1), a particular pipe 106 may be located within a stack. Based on the identifier of the particular pipe 106, the database 126 (see FIG. 1) may be accessed in order to obtain history information in real-time. A stand-alone sensor 1324 is further provided at the entrance of the storage yard 1320, in order to detect assets entering and leaving the yard, thereby facilitating real-time inventory management of the assets and preventing unauthorized transportation of assets.
In accordance with an embodiment, the afore-mentioned method may further comprise, after installation of the asset storing, in the database 126, operational procedures relative to an asset 105. The method further includes generating a procedure message for presenting the operational procedures on the user-interface of the remote device. The method further includes receiving from the remote device, status information relative to the operational procedures. The completion status represents a "completed task" or an "uncompleted task". The method further includes associating a completion status in the database 126, to each of the operational procedures based on the status information received.
Preferably, a set of such operational procedures are defined in the database in relation to given stages in the lifecycle of the asset, after installation (examples of such stages include: a maintenance of an installed asset, a prescheduled verification, a displacement of an installed asset, scheduled replacement of the asset, etc.). At a given stage, or shortly before or thereafter, the remote device may display the operational procedures, via the afore-mentioned client device, on the user-interface for viewing by an operator. The client application, then receives the status information, which may be input manually by the operator or entered automatically further to completing an operational task, as to whether the procedure was successfully completed or not. Preferably, status information is received for each procedure presented. Input validation rules may be provided to process some of the status information. For example, when a given procedure is marked as non-completed, then other procedures depending on this given procedure are automatically marked as non-completed.
The method may further comprise: if one of the procedure is identified as having a status representing a non-completed task, generating an exception report identifying the asset and the procedure. This step may be executed at the above-mentioned given stage, or at a later stage in the lifecycle of the asset. The exception report is preferably sent for presentation on the same remote device, to return a message to the operator, or another remote device, for control purposes for example.
Embodiments of the present invention are advantageous in that for example the introduction and maintenance of the records in the database is subjected to validation and verification, in order to promote the integrity of the data in the database 126, thereby allowing to meet operators' and regulators' compliance requirements.
Examples: traceability of pipe sections A particular embodiment directed to the traceability of pipe sections for constructing pipeline infrastructure will now be described, as an example, with reference to FIG. 18 and 19. Broadly, transportable identification tags each storing data related to a particular one of the assets are each placed on a first location of the pipe section, and subsequently placed, further to a handling of the asset, on a second location of the pipe section.

More particularly, FIG. 18 shows a pipeline traceability system 100, in the context of a fabrication plant 200 and of a coating plant 202. As can be seen, with further reference to FIG. 21A-21C and 22A-22C, the pipeline traceability system 100 includes: a source database 102 (that may be located at the fabrication plant 200) for storing data 104 related to a plurality of pipes 106 (that are examples of manufactured parts that will become infrastructure assets) to be traced; an RFID tag 108 associated to one of the plurality of pipes 106, the tag 108 including a data storage medium 110 for an identifier 109 associated to the corresponding pipe 106, a first securing means 114 for temporarily securing the tag 108 to a first location 116 of the pipe 106, and a second securing means 118, for securing the tag 106 to a second location 120 of the pipe 106; and a scanner (preferably a reader and writer) 122 adapted to retrieve the data 104 associated to the corresponding one of the plurality of pipes 106 from the source database 102 and to communicate with the tag 108 in order to store the read identifier 109onto the data storage medium 110 of the tag 108.
The system 100 may include two main hardware components, namely a host server 124 and RFID tags 108. A scanner 122 is also provided. The scanner 122 comprises a client application stored thereon in order to interact with the tag 108 and with the source database 102.
In the fabrication plant 200, the following steps are carried out, with reference to FIG. 18.
At step (1), the host server 124 communicates with the fabrication plant's 200 database 102, in order to obtain a unique identifier 109 and all available data 112 on the asset being tracked (e.g. pipe 106). The data 112 may include a heat and lot number. The host server 124 may be synchronized with the fabrication plant's database 102 to ensure that the correct data is being associated to the tags 108.
At step (2), the host server 124 communicates with the scanner 122 to transfer pertinent data 112 on the asset 106 being tracked to the scanner 122 and verify the integrity of the data transfer. The data 112 pertaining to the asset 106 is obtained from the fabrication plant's database 102.
At step (3), the scanner 122 communicates with the tags 108 and writes the respective identifiers 109 obtained from fabrication plant's database 102 to the tags 5 108 as well as receives confirmation 113 that the data has been written correctly. The data displayed on the screen 126 of the scanner 122 may be synchronized with the process at the fabrication plant 200 to ensure that the pipes 106 being fabricated are being labeled with the appropriate identifiers. Human verification may be done by visually comparing the identifier displayed on the screen of the scanner 122 with the 10 identifier displayed on the pipe 106 before writing to the tag 108 (quality control).
At step (4), the host server 124 writes all data 112 pertaining to the tagged pipe 106 (obtained from the fabrication plant's database 102) to the host database 126 through a network connection 128, such as Ethernet, WiFi, 3G, 4G, or the like. In addition to the data 112 from the fabrication plant 200, additional data 113 such as a 15 confirmation that the tags 108 were written and the labels were manually verified is added to the host database 126. It should be noted that the host database 126 may be offsite (for example, in a different city) and the data 113 transferred to host database 126 may include additional information other than the manufactured asset data.
20 According to an alternative embodiment, the data 112 obtained from the fabrication plant's interface at step (3) is not transcribed onto the tags 108, in order to protect the data 112. Thus, only the unique identifier 109 is stored in the RFID tag's 108 memory 110.
In the context of the present description, the "memory" 110 may be any suitable 25 transportable storage device capable of storing digital information. In the case of an RFID tag, the storage device is a memory chip.

The interactions at the fabrication plant 200 shown in FIG. 18 will now be summarized. Initially, when a pipe 106 is scheduled for fabrication, the database 102 at the fabrication plant 200 starts communicating with the host server 124.
Once the pipe 106 is fabricated and all the required tests have been completed, the database 102 at the fabrication plant 200 signals the host server 124 and provides the host server 124 with an identifier 109 associated with the manufactured pipe 106 (step 1).
The host server 124 transfers the pipe's identifier 109 to the scanner 122 (step 2). A
user, such as a fabrication plant worker, visually verifies that an identifier displayed on the scanner 122 matches the identifier appearing on the pipe 106 and encodes the tag 108 with the pipe's data 112 obtained from the host server 124 (step 3).
The scanner 122 receives confirmation that the tag 108 was written with the pipe identifier 109 (step 3) and the confirmation is transferred to the host database 102 (step 4) through the host server 124. At this point, the identifier 109 received from the fabrication plant's database 102 is transferred to the host database 126 (step 4). It should be noted that this data transfer may also occur immediately at step (1).
During the manufacturing process, an RFID tag or other identification tag, such as a barcode may be mounted on the asset 106, in order to record in the database information regarding tests carried out on the asset 106 during the manufacturing process. Typically, three labels having bar codes marked thereon are mounted on the pipe, for reading during particular steps of the fabrication. The bar codes are preferably removed after the manufacturing process.
The steps carried out in the coating plant 202 will now be described, still with reference to FIG. 18.
At step (5), a scanner 122 communicates with the tags 108 and reads the identifier 109 prior to exiting the coating plant 202. Preferably, there is at least a first scanner 122 at the fabrication plant 200 and at least a second scanner 122 at the coating plant 202.

At step (6), the scanner 122 communicates with the host server 124 to add confirmation data 115 to the host database 126 indicating that the asset has completed all the required steps at the coating plant 202. The tags 108 provide the host database 126 with information to identify the asset 106 and facilitate populating the database 126. It should again be noted that the host database 126 may be offsite (for example, in a different city) with respect to the coating plant, and that the data transferred to the host database 126 is not limited to a confirmation 115. The scanner 122 also communicates with the host server 124 to receive the status 117 of the data being written to the database 126.
At step (7), the host server 124 communicates with the host database 126 to populate the database 126 with data from the coating plant 202 which is associated with the tags 108 (e.g. confirmation 115). The host server 124 verifies that the data has been correctly written to the host database 126 and provides the scanner 122 with a status report 119.
At step (8), the scanner 122 may replicate tags 108 for redundancy when necessary (e.g. the scanner 122 may have a copy-and-paste function to facilitate the replication of tags 108 for redundancy). Replicated data, i.e. identifier 109, may be added to host database 126 (e.g. the host database 126 is updated with all new tag information 130).
The interactions occurring at the coating plant 202, shown in FIG. 18, will now be summarized. Once the pipe 106 arrives at the coating plant 202 from the fabrication plant 200, the pipe 106 undergoes several steps until the final coating is applied.
Although the data for these steps are not necessarily tracked, the system has the ability to track this data. After the pipe 106 is coated, an employee at each end of the pipe 106 may scan the tags 108. The data 112 from the tags 108 can be used to populate the host database 126 through the host server 124 and the status of populating the database 126 can be sent back to the scanner 122 from the host database 126 through the host server 124. Workers may visually verify that the status on the scanner 122 indicates that the data was successfully written to the database 126 (quality control). In the event that a new tag 108 is needed, replication is initiated by the worker(s) and the host database 126 is populated using the same system for the new tag(s) 108.
It is to be understood that, according to an alternative embodiment, the scanner 122 at the fabrication plant 200 may be in direct communication with the source and host databases 102, 126, as exemplified in FIG. 23, so as to write directly to the database 102, 126 (i.e. send data from the scanner directly to the database 102, 126).
Similarly, still with reference to FIG. 23, the scanner 122 at the coating plant 200 may be in direct communication with the host database 126, in order to transfer data directly thereto.
Thus, in some embodiments, the tag may include communication means for communicating with a tag reader and/or tag writer device (also referred to herein as "scanner"). The tag reader device and tag writer device may preferably be the same scanner device, though they may be different devices.
Referring now to FIG. 19, the pipeline traceability system 100 at deployment in the field 204 will be described. Shown in FIG. 19 are two particular cases ("Case A" and "Case B") where the scanner 122 communicates with tag(s) 108.
Case A, represented by step (9) in FIG. 19, applies when the asset 106 is deployed.
The scanner 122 communicates with the tag 108 and reads the data 112 (see FIG.
21A-21C), upon deployment of the asset 106.
Case B, represented by step 10 in FIG. 19, applies when changes occur to the structure of the asset 106, such as when the asset 106 is split into several unattached parts, e.g. cutting a pipe 106 into several smaller sections 106i, 106ii, 106iii, as exemplified in FIG. 22C. Still referring to FIG. 22C, the scanner 122 communicates with the original tag 108a placed at the fabrication plant 200 and reads the data 112a therefrom. A new tag 108b is added to each unattached part 106ii of the asset that is without such a tag. The scanner 122 replicates the data 112a from the original tag 108a to all new tag(s) 108b using a copy-and-paste function. Replicated data 112b is added to host database 126 (i.e. the host database 126 is updated with all new tag information 112b), as illustrated in FIG. 19.
The uploading of the data to the host database 126 via the scanner 122 will now be described according to two methods, namely methods "A" and "B", also illustrated in FIG. 19.
Method A, represented by steps 11 and 12 in FIG. 19, involves the host server 124.
At step (11), the scanner 122 communicates with a host server 124 a network connection 128, such as Ethernet, WiFi, 3G, 4G, or the like to add confirmation data 119 to host database 126 indicating that the asset 106 has been deployed.
It should be noted that the host database 126 may be offsite (could be in a different city) and the amount of data transferred to the host database 126 is not limited to a confirmation 119. The host server 124 returns the status 121 of the data written to the database 126 (e.g. a confirmation that the data was written correctly to the database) to the scanner 122.
At step (12), the host server 124 communicates with the host database 126 to populate the database 126 with data from the field; data that is associated with the tags 108 (e.g. confirmation data 119). The host server 124 verifies that the data has been correctly written to the host database 126 and provides the scanner 122 with a status report through the host server 124.
According to method B, the scanner 122 communicates with the host database 126 directly over a secure network connection 128, such as Ethernet, WiFi, 3G, 4G, and/or the like, as represented by step (13) in FIG. 19, in order to populate the database 126 with data from the field, i.e. the data associated with the tags 108 (e.g.
confirmation data 119). The scanner 122 verifies that the data has been correctly written to the host database 126.

It is to be understood that the data transfer from the pipes 106 in the field 204 to the host database 126 may be accomplished in a variety of alternative methods. A
limiting factor may be accessibility to a network. If a network exists, then the data from the tags 108 may be transferred to the database 126 through a host server 5 or directly using 3G, 4G, or the like. If no such broad network is available to service the tag 108, then the scanner 122 may be used to read the tag, and then be connected to a computer (or enter in communication with the computer when located in proximity thereto or via a network connection) in order to upload the data to the host database 126 at a later time when a communication network is accessible.
10 The interactions occurring in the field 204, shown in FIG. 19, will now be summarized.
After the pipes 106 are coated at the coating plant 200, they are transported to the field 204 to be either deployed or cut into smaller sections to fit a particular length before deployment. In the former case, the scanners 122 are used to scan the tags 108 and populate the host database 126 with data associated with the deployment of 15 the asset. In the latter case and as exemplified in FIG. 20C, the scanners 122 are used to replicate the original data 112a from the tags 108a at either end of the pipe 106 to all new tag(s) 108b. The scanner 122 is then used to scan the new tags 108b and populate the host database 126 with all pertinent data at the time of deployment.
The host database 126 may be populated either through a host server 124, directly 20 using a secure network 128, or physically connecting the scanner 122 to the host database 126 using a secure network line.
Referring now to FIG. 20A-20C, the method for providing pipe traceability from construction (at the fabrication plant 200), to the coating plant 202, and then to deployment of pipes in the field 204, will be described.
25 Referring to FIG. 20A, at the fabrication plant 200, the tags 108a are placed inside 116 the pipe 106 at a pre-determined distance to ensure the tag 108a is protected during structural tests and not lost or damaged during the cleaving procedure (a minimum required distance is set by a cleaving procedure), and then encoded using scanners 122 (see FIG. 18). As better illustrated in FIG. 20C, tags 108a are placed, by means of a first securing means such as a magnet 114 for example (see FIG.

21C), at both ends of the pipe 106 to ensure redundancy (i.e. multiple tags 108a reduce the probability of data loss) and insensitivity to pipe orientation, which can be an issue along the process pipeline.
Referring to FIG. 20B, after the final step at the coating plant 202, the tags 108a at both ends of the pipe 106 are moved from the inside 116 of the pipe 106 to the outside 120 of the pipe 106, at each end 106i, 106iii of the pipe 106. A
secondary adhesive 118 (see FIG. 22A-22C) is used to secure the tags 108a to the outside of the pipe 106. The tags 108a are placed near the seam and contralateral to each other (i.e. if a tag is placed to the left of the seam, the other tag 108a is placed to the right of the seam). The tag 108 is used to encode completion of coating.
In the field 204, a pipe 106 may be cut to fit a particular length prior to deployment, as previously mentioned with reference to FIG. 20C. Although a single cut should not affect the traceability of a pipe, multiple incisions would compromise pipeline traceability. In the event that a pipe 106 is cut in multiple locations, new tag(s) 108b are placed on all pieces 106ii of pipe that do not have such a tag. The data is copied from the original tags 108a at either end of the pipe 106 and used to encode the new tags 108b. The new tags 108b are secured with a secondary securing mechanism 118. If multiple incisions are made, all unmarked pieces of pipe are tagged using the above procedure.
Preferably, the afore-mentioned "first location" is a protected location on the asset and the "second location" is an exposed location of the asset. For example, in the context of pipelines, where the asset is a pipe section, the first location may correspond to an inner portion of the pipe section and the second location may correspond to an outer portion of the pipe section.

By "securing means" it is meant any suitable mechanism, assembly, sub-component thereof, or material for fastening, attachment, mounting, adhering, etc. the tag to the asset.
Furthermore, it is to be understood that, according to embodiments of the present invention, the tag 108 may be initially placed on the pipe 106 at the steel manufacturer (i.e. steel mill), at the pipe manufacturer (i.e. pipe mill) or at the coating company 202, or even at any step prior to deployment of the pipe 106 into the field 204, for example at a storage location.
The tag 108 may be mounted on the pipe 106 manually by a worker or it may be applied by an automated system, for example by means of a robotic arm.The securing mechanisms used in this embodiment are divided into two groups:
primary stage and secondary stage. Securing mechanisms 114 in the primary stage, shown in FIG. 21A-21C, are used to temporarily bind the tags 108a to the pipe 106 before the tags 108a are transitioned to their final location and the securing mechanisms 118 in the secondary stage, shown in FIG. 22A-22C, are used to permanently bind the tags 108 to the pipes. The primary stage is necessary because the tags 108 need to be placed in a location that is protected from the harsh testing and coating treatment performed on the pipes before they can be placed in a location where the scanner 122 can more readily communicate with the tags 108.
Referring now to FIG. 21A-21C, primary stage securing mechanisms will be described, according to embodiments of the invention. The tags 108 may have a magnetic portion 114 and peel away section that composes the primary stage securing mechanism (FIG. 21A-21C). At the fabrication plant 200 the magnetic portion 114 of the tags 108 are used to attach the tags 108 to the interior of the pipe.
At the coating plant 202, the tags 108 are moved from the inside 116 to the outside 120 of the pipe 106 (see FIG. 20B) and a peel away adhesive layer 118 may be used to attach the tags 108 to the pipe 106 before the secondary stage securing mechanism is applied. The primary securing mechanism may be a chemical adhesive such as glue. The primary securing mechanism may also be a mechanical device that is adapted for mounting within a pipe section.
Referring now to FIG. 22A-22C, secondary stage securing mechanisms 118 will be described, according to embodiments of the invention. Three kinds of secondary securing mechanisms 118 are shown: spray on (FIG. 22A), over paint (FIG. 22B), and tape (FIG. 22C). Each secondary securing mechanism 118 may be applied to the tags 108 after they have been placed in their final location. This may occur after the last step at the coating plant 202 or in the field 204 when new tags 108 have been added (see FIG. 20A-21C). The secondary securing mechanisms 118 have been designed to produce a durable permanent bind to the asset that can endure extreme conditions.
Another particular embodiment directed to the traceability of drilling pipes, e.g. OCTG
(Oil Country Tubular Goods), will now be described, as an example, with reference to FIG. 28 and 29. An OCTG drilling pipe does not require a coating procedure because the pipe is used dynamically, in that it is used from one drilling location to another (i.e it does not remain in a same location for long periods of time as is the case of a pipe serving as a segment of a pipeline). Instead, once the pipe is fabricated, the pipe is ready for use in the field. The identification tags are therefore not exposed to the same environmental constraints as afore-described pipes that require coating.
FIG. 28 illustrates a drilling pipe 106. At the fabrication plant 200, identification tags 108 are placed outside of the pipe 106 once the pipe is manufactured.
Identification tags 108 are placed at both ends of the pipe 106 to ensure redundancy, as multiple identification tags reduce the probability of data loss, and insensitivity to pipe orientation, which can be an issue along the process pipeline. An adhesive, such as the secondary adhesives 118, described herein with reference to FIG. 22A, 22B, 22C, is used to permanently secure the identification tags 108 to the pipe 106. The identification tags 108 are placed near a seam 107 of the pipe 108 and contralateral to each other, that is to say if a first identification tag 108 is placed to one side of the seam 107, the other identification tag 108 is placed to the other side of the seam 107.
Referring now to FIG. 29, the pipeline traceability system 150 at deployment in the field 152 will be described. The system 150 includes two main hardware components, namely a host server 124 and the scanner 122.
At step (14), the scanner 122 communicates with the identification tag(s) 108 by automatically reading each tag 108 as the drilling pipes 106 are deployed into the ground.
The uploading of the drilling pipe data to the host database 126 will now described according to two methods, namely methods "A" and "B", still with reference to FIG.
29.
Method A, represented by steps 15 and 16, involves the host server 124. At step (15), the scanner 122 communicates with a host server 124 over an on-site hard-wired network link 127, in order to add confirmation data 119 to host database 126 indicating that the asset 106 has been deployed. It is to be understood that the communication between the scanner 122 and the host server 124 may also be provided over any suitable communication network, including Ethernet, WiFi, 3G, 4G, or the like.
It should be noted that the host database 126 may be offsite (may be in a different city, for example) and the amount of data transferred to the host database 126 is not limited to the confirmation 119. The host server 124 returns the status 121 of the data written to the database 126 (e.g. a confirmation that the data was written correctly to the database) to the scanner 122.
At step (16), the host server 124 communicates with the host database 126 in order to populate the database 126 with data from the field, i.e. data that is associated with the tags 108 (e.g. confirmation data 119). The host server 124 verifies that the data has been correctly written to the host database 126 and provides the scanner with a status report through the host server 124.
According to method B, the scanner 122 communicates with the host database 126 directly over a secure line 129, as represented by step (17) in FIG. 29, in order to 5 populate the database 126 with data from the field, i.e. the data associated with the tags 108 (e.g. confirmation data 119). The scanner 122 verifies that the data has been correctly written to the host database 126. It is to be understood that the communication between the scanner 122 and the host server 124 may also be provided over any suitable communication network, including Ethernet, WiFi, 3G, 4G, 10 and/or the like The interactions occurring in the field 152, shown in FIG. 29, will now be summarized.
After the pipes 106 are made at the fabrication plant 200 (FIG. 28), they are transported to the field 204 where they will be used for drilling. An automated scanner 122 is used to scan the tags 108 as the pipes are deployed into the ground and 15 populate the host database 126 with data associated with the deployment of the asset. The host database 126 may be populated either through a host server 124, directly using a secure network line 129, where the scanner 122 is physically connected to the host database 126 using a secure network line.
Advantageously, embodiments of the present invention increases source data 20 integrity in comparison to conventional systems, by transferring the source information 1018, including metallurgical data of the source manufacturer 302, 312, 322 from one (or more) database 1016 (or spreadsheet or the like) to another database (or spreadsheet or the like), thereby reducing human intervention and consequently reducing human error. Data is further verified at various steps and 25 stages in the lifecycle of the asset 105, further promoting the integrity of the data recorded in the database 126.
Furthermore, in the case of pipe assets 106, the steel mill producing the coil or the pipe manufacturer producing the pipe provides the host database 126 with the source data 1018 in electronic form and that data 1018 remains associated with the asset 106 for the life of the asset 106. Furthermore, events occurring to the pipe section 106 may be added in the database 126 as history data 1023. Thus, the source data as well as the event history of a particular pipe 106, remains available for distribution to an end user.
Still advantageously, according to embodiments of the present invention, one or more of the tag 108 may be embedded into the pipe either during the pipe manufacturing process which may include the coating process. Of course, the tag may be mounted on the pipe after coating. A permanently placed tag 108 is configured to withstand the rigors of the manufacturing process and to permanently stay with the pipe 106 for the life of that pipe 106.
Still advantageously, the tag 108 is useful for the entire lifecycle of the pipe 106. For the purpose of inspecting a pipeline that has been installed, a worker may access information concerning a particular pipe of the pipeline via a scanner 122, which may be provided by a smartphone. By means of the smartphone, the worker accesses, via an application interface executed on the smartphone, history information related to this particular piece of pipe, including manufacturing source data as well as every event that has occurred to that pipe since its manufacturing.
At the time of underground installation of a pipeline in the field 204, a longitude and latitude is plotted by a survey company, for referencing each pipe 106 to a map. The scanner 122 reads the tag 108 of a given pipe 106 and communicates with the host database 126, in accordance with the method shown in FIG. 19, to associate the pipe 106 with the longitude and latitude for future identification of the particular pipe 106 and the retrieval of corresponding information. It is to be understood that a similar plot reference may also be associated to a pipe 106 installed above ground.
Alternatively, an above-ground pipe 106 is readily accessible for identification by a scanner 122, and it may therefore not be necessary to reference it to a map.

Thus, this embodiment provides a field reporting feature, in that the inventory or other asset information may be retrieved on the basis of the location of the pipes 106 as they are displaced in the field 204. The field reporting feature is advantageous over conventional inventory management systems that generally provide theoretical or static inventory information, in that the field reporting feature is based on data 112 tied to the physical assets 106 deployed in the field 106.
In accordance with an embodiment of the present invention, the host database and host server 124 are hosted by host company. A client company owns assets and uses tags 108 for identifying their assets 106. The host database 126 stores information 112 related to the tags 108 and assets 106 of the client company.
The client company may access the host database 126 for their particular tags 108 and assets 106, in exchange for a fee charged based on a volume of tags 108 to be used by the client company. This fee may vary for example between 20$ to 300$ per asset.
Alternatively, the client company may purchase a corporate license for accessing the host database independently of the number of tags 108, for example when the number of tags 108 used by a client company exceeds a given threshold.
Several modifications could be made to the above-described asset traceability system, without departing from the scope of the present invention. Indeed and for example, the first securing means 114 may include a mechanical apparatus such as a tripod spreader 132 (7A, 7B), a bar spreader 134 (see FIG. 25A, 25B), a wire spreader 136 (26A, 26B), a custom spreader 138 (see FIG. 27A to 27D), as well as any other suitable securing system including multi-pod spreaders, compression spring systems, ratchet based systems, expansion rings, suction cups, latches, and hooks, adhesions like glue, tape, and magnetic materials.
The system may also include heat protection means for protecting the RFID tag from the elevated temperatures of the coating process. The heat protection means may hold the RFID tag in spaced relation with respect to the interior surface of the pipe section and may be composed of a material with low heat conductivity. The heat protection means may also include encasings that act as a buffer between the heat and RFID, insulation material to envelop the RFID, and spray on chemicals that dissipate prior to the heat affecting the RFID.
Other optional aspects and implementations Various optional scenarios and examples of systems, methods and certain components for pipeline asset traceability techniques will be described below.
It should be understood that the scenarios described below may be combined with other aspects of the traceability as described hereinabove in accordance with various embodiments of the present invention.
In some scenarios, there is provided a pipeline asset traceability method for tracking coated pipeline assets from manufacturing to deployment, the method including:
temporarily tagging manufactured pipe sections by removably mounting an identification tag at a protected location within each of the manufactured pipe sections, such that each of the identification tags is protected with respect to a post-manufacturing coating treatment of an outside surface of each of the manufactured pipe sections to produce the coated pipeline assets, wherein each of the identification tags includes a readable-and-writable data storage medium storing pipe manufacture data associated with the corresponding manufactured pipe section;
removing each of the identification tags from the protected location within each of the coated pipeline assets after the corresponding post-manufacturing coating treatment;
re-tagging the coated pipeline assets by mounting each of the removed identification tags to an outer coating of a corresponding one of the coated pipeline assets; and deploying the tagged coated pipeline assets for construction of pipeline infrastructure.
In accordance with another scenario, there is provided a pipeline asset traceability system for tracking coated pipeline assets from manufacturing to deployment, the system including:
a set of identification tags, each identification tag including:
a readable-and-writable data storage medium; and a first mounting mechanism for removably mounting the data storage medium at a protected location within a manufactured pipe section, such that each data storage medium is protected with respect to a post-manufacturing coating treatment of an outside surface of the manufactured pipe sections to produce the coated pipeline assets;
a secondary mounting mechanism for re-installing each data storage medium to a corresponding outer surface of each of the coated pipeline assets;
a database for receiving pipe manufacture data associated with each of the manufactured pipe sections; and a scanner for receiving the pipe manufacture data from the database and writing the pipe manufacturing data associated with each of the manufactured pipe sections to the corresponding data storage medium mounted to the corresponding coated pipeline asset, and for reading the pipe manufacture data from each of the tags, thereby allowing traceability of the coated pipeline assets.
It is to be understood that the pipe manufacture data may be uploaded to the tag in a number of ways. Indeed and for example, the tag may be in communication with the host server or source database so as to receive corresponding information directly therefrom, instead of having the scanner write to the identification tag. In some aspects, the pipe manufacture data or a portion thereof is pre-stored in the tag prior to mounting the tag onto the pipe.
In accordance with another scenario, there is provided a pipeline asset traceability system for tracking coated pipeline assets from manufacturing to deployment, the system including:
a database for storing pipe manufacture data associated with manufactured pipe sections;
a set of tags, each tag including:
10 a data storage medium for receiving pipe manufacture data associated with one of the manufactured pipe sections; and a first mounting mechanism for removably mounting the tag at a protected location within the corresponding manufactured pipe section, such that each data storage medium is protected with respect to a post-manufacturing coating treatment of an outside surface of the manufactured pipe sections to produce the coated pipeline assets;
a secondary mounting mechanism for re-installing each data storage medium to a corresponding outer surface of each of the coated pipeline assets; and a scanner for obtaining the pipe manufacture data from each of the tags, 20 thereby allowing traceability of the coated pipeline assets.
In accordance with another scenario, there is provided a traceability tag for tagging coated pipeline assets for tracking from manufacturing to deployment, the traceability tag including:
a readable-and-writable data storage medium for receiving pipe manufacture data associated with a manufactured pipe section and providing the pipe manufacture data to ensure traceability of the coated pipeline asset including the manufactured pipe section;
a mounting mechanism connected with respect to the readable-and-writable data storage medium, for removably mounting the same at a protected location within the manufactured pipe section; and heat protection means connected with respect to the readable-and-writable data storage medium, such that the readable-and-writable data storage medium is protected from temperatures up to about 250 C in the post-manufacturing coating treatment.
The heat protection means may be provided for protection of the data storage medium from temperatures up to about 300 C, 350 C, 400 C, 450 C or 500 C, in the post-manufacturing coating treatment. The heat protection means may include a structure or composition enabling the data storage medium to resist or minimize heat transfer from other parts of the hot pipe section while the pipe section is undergoing coating, thereby allowing the data storage medium to remain at lower temperatures until the coated pipe section is quenched and cooled.
In accordance with another scenario, there is provided a traceability kit for tracking coated pipeline assets from manufacturing to deployment, the traceability kit including:
a readable-and-writable data storage medium for storing pipe manufacture data associated with a manufactured pipe section, in order to ensure traceability of the coated pipeline asset including the manufactured pipe section;
a first securing mechanism for cooperating with the readable-and-writable data storage medium, to removably secure the same at a protected location within the manufactured pipe section; and a second securing mechanism for cooperating with the readable-and-writable data storage medium, for re-securing the same with respect to an outer surface of the coated pipeline asset.
In accordance with yet another scenario, there is provided an identification tag for tracking an asset, the identification tag including:
a data storage medium for storing data associated to the asset; and a securing means adapted to cooperate with the data storage medium to temporarily secure the data storage medium to a first location of the asset and to subsequently secure the data storage medium permanently to a second location of the asset.
In accordance with still another scenario, there is provided an identification tag for tracking an asset, the tag including:
a data storage medium for storing data associated to the asset;
a first securing means adapted to cooperate with a protected location of the asset to temporarily secure the data storage medium to said protected location of the asset; and a second securing means adapted to cooperate with an exposed location of the asset to permanently secure the data storage medium to said exposed location of the asset.
The above-mentioned data storage medium may include a memory. By "memory" it is meant any suitable transportable storage device capable of storing digital information.
Indeed, and for example, the identification tag may take the form of a radio frequency identification (RFID) tag, wherein the data storage medium is a memory chip.
Alternatively, the data storage medium may be provided in the form of a bar code, magnetic stripe, any suitable electronic chip and/or the like. The data storage medium is preferably readable and rewritable.
In some embodiments, the tag may further include communication means for communicating with a tag reader and/or tag writer device (also referred to herein as "scanner"). The tag reader device and tag writer device may preferably be the same scanner device, though they may be different devices.
In accordance with yet another scenario, there is provided an asset traceability system including the above-described tag. More particularly, the asset traceability system includes:
a source database for storing data related to a plurality of assets to be traced;
a tag associated to one of the plurality of assets, the tag including a data storage medium for storing data associated to the asset;
a securing means adapted to cooperate with the data storage medium to temporarily secure the data storage medium to a first location of the asset and to subsequently secure the data storage medium permanently to a second location of the asset; and a scanner for reading data stored on the data storage medium of the tag secured to one of said plurality of assets, in order to trace the corresponding asset.
In an embodiment, the system further includes a host server being in communication with the source database over a communication network.
In an embodiment, the scanner is adapted to communicate with the source database in order to retrieve therefrom the data associated to the corresponding one of the plurality of assets, and to communicate with the tag in order to store the read data onto the data storage medium of the tag.

In accordance with yet another scenario, there is provided a pipeline asset traceability method for tracking non-coated pipeline assets from manufacturing to deployment, the method including:
tagging manufactured pipe sections by mounting an identification tag to an outer surface of each of the manufactured pipe sections, wherein each of the identification tags includes a readable-and-writable data storage medium;
storing on each on the readable-and-writable data storage medium, pipe manufacture data associated with the corresponding manufactured pipe section; and deploying the tagged manufactured pipeline assets for construction of pipeline infrastructure.
Preferably, an identification tag is placed at each end of each of the manufactured pipe sections at the tagging step. Preferably, each of the pair of identification tags for a given pipe section are mounted near a seam of the pipe section and contralateral to each other, in that a first one of the pair is mounted on one side of the seam while a second one of the pair is mounted on the other side of the seam.
In accordance with another scenario, there is provided a pipeline asset traceability system for tracking non-coated pipeline assets from manufacturing to deployment, the system including:
a set of identification tags, each identification tag including a readable-and-writable data storage medium;
a mounting mechanism for installing each identification tag to an outer surface of a corresponding one of the manufactured pipeline assets;

a database for receiving pipe manufacture data associated with each of the manufactured pipe sections; and a scanner for receiving the pipe manufacture data from the database and writing the pipe manufacturing data associated with each of the manufactured 5 pipe sections to the data storage medium of the identification tag mounted to the corresponding coated pipeline asset, and for reading the pipe manufacture data from each of the tags, thereby allowing traceability of the manufacture pipeline assets after deployment.
In accordance with yet another scenario, there is provided a method for tracing an 10 asset by means of the afore-mentioned tag and system. More particularly, the method includes steps of:
providing a tag including a data storage medium, having stored thereon data associated to the asset;
securing the tag temporarily to a first location of the asset for a treatment of the 15 asset; and further to said treatment of the asset, securing the tag on a second location of the asset.
The method preferably includes, prior to the step of providing a tag, the step of storing the data associated to the asset on to said data storage medium of the tag, by means 20 of a writer (or scanner) such as the one described above.
For example, in the case where the asset is a pipe, the scanner may first retrieve information from the host database, related to a particular pipe section asset and feeds this data onto the data storage medium of the tag. Thus, the tag stores data related to a specific pipe section, for example a heat and lot number, as well as a 25 unique identifier of the tag, i.e. example of step of providing a tag.
Upon fabrication of the corresponding pipe section, the tag is secured inside the pipe, i.e.
example of step of securing the tag on a first location. The pipe section is then subjected to various one or more post-manufacture treatments, which may include heating, sandblasting, acid washing, coating, cooling, cleaning, etc. Further to a coating treatment, the tag is removed from the inner portion of the pipe and then secured to the outside of the pipe, i.e. example of step of securing the tag on a second location.
At any of the above-mentioned steps or at any intermediate sub-step thereof, data may be read from the tag, for verification purposes for example, and/or data may be written on the tag, for example when new information is relevant, such as when a treatment or testing step has been completed. Another example where new information is created occurs when a given pipe asset is split or cut into two or more smaller pipes prior to deployment. In this case, for each cut, a separate untagged pipe asset is created and a new tag is thus provided on the new pipe asset and the pipe manufacture data is written onto the new tag. The data may be read from the tag of the cut pipe asset having the original tag, and then written onto the new tag of the other cut pipe asset. After the tag information is updated with this new information (for a previously existing tag and/or for a newly created tag), the scanner also preferably updates the host database, in order to centrally store the new information.
Alternatively, some of the new information is generated from the host database for the scanner to feed onto the tag. Status information related to the tag may then be transferred back to the host database.
Thus, the afore-mentioned method preferably includes reading the data stored on the data storage medium, via the scanner before, after or during steps of providing a tag, of securing the tag on a first location and/or of securing the tag on a second location.
For example, the read data may be presented on the display screen of the scanner for verification purposes, at different steps in the testing and treatment of the pipe.
The method may further include updating the data stored on the data storage medium after steps of providing a tag, of securing the tag on a first location and/or of securing the tag on a second location, via the scanner.

Preferably, the method may include retrieving the updated data from the tag, preferably via the scanner, and updating the host database.
In another scenario, there is provided a pipeline asset traceability method for tracking a pipeline asset for deployment in a pipeline infrastructure, the method including:
securing a first identification tag including a data storage medium to the pipeline asset, the data storage medium storing pipe data related to the pipeline asset;
cutting the pipeline asset into at least first and second pipeline asset parts, the first pipeline asset part having the first identification tag secured thereto;
retrieving the pipe data from the data storage medium of the first identification tag;
providing the retrieved pipe data to a second identification tag secured to the second pipeline asset part; and deploying the first and second pipeline assets in the pipeline infrastructure.
Although some embodiments as illustrated in the accompanying drawings includes components such as a source database, a host server, a scanner, an RFID tag, securing mechanisms such as glue, a magnet, adhesives, etc., and although the preferred embodiment of the asset traceability system and corresponding parts thereof include certain configurations as explained and illustrated herein, not all of these components and configurations are essential to the invention and thus should not be taken in their restrictive sense, i.e. should not be taken as to limit the scope of the present invention. It is to be understood, as also apparent to a person skilled in the art, that other suitable components and cooperations therein between, as well as other suitable configurations and architectures may be used for the asset traceability system according to the present invention, as will be briefly explained herein and as can be easily inferred herefrom, by a person skilled in the art, without departing from the scope of the invention.
Furthermore, although the present description provides examples and aspects related to pipelines and other assets in the field of oil and gas, the present invention may be applicable to other similar assets which require or would benefit from tracking and managing, and which in some cases may be limited in terms of location where identification information may be placed while they are being handled, as can also be easily understood by a person skilled in the art, without departing from the scope of the present invention. Various techniques are described herein in relation to traceability of pipeline assets, for example coated or uncoated pipeline assets. The assets may be dedicated for deployment in a pipeline infrastructure for transporting gas, liquid, suspensions or slurries various distances. The assets may therefore have properties and structures suited for the dedicated purpose. The pipeline assets may be for use in the petro-chemical industry, the energy industry or other industries such as waste and sewage management, water and air treatment, construction, and so on.
It should be noted moreover that many other types of infrastructure assets, in the field of oil and gas or in other fields, may be tracked using techniques as described herein.
Such assets may include transportation infrastructure assets that are pre-fabricated prior to deployment, such as railroad component assets, road component assets, building component assets, and so on.
Additionally, although the present description provides examples and aspects related to pipes made of a metallic composition, it is to be understood that the present invention may be useful for pipes or other assets made of other compositions, for example polyethylene pipes.
In addition, according to embodiments of the present invention, components or devices additional to those described herein, may be incorporated with the above-described systems, methods and/or components thereof, without departing from the scope of the invention, as can be understood by a person skilled in the art.

The above-described embodiments are considered in all respects only as illustrative and not restrictive, and the present application is intended to cover any adaptations or variations thereof, as apparent to a person skilled in the art. Of course, numerous other modifications could be made to the above-described embodiments without departing from the scope of the invention, as apparent to a person skilled in the art.

Claims

Claims:

1. A system for tracking and managing oil and gas infrastructure assets, an identification tag being mounted on each asset and storing a unique identifier, the system comprising:
a data importation module, integrated in a processor and configured to communicate with a manufacturer data source, for receiving manufacture information related to one of the assets from the manufacturer data source, the data importation module comprising a validation module for validating the manufacture information based on data integrity rules stored in a memory, the data importation module being further configured to receive history information related to the asset from a plurality of entities, during a lifecycle of the asset;
a central database being in communication with the data importation module, for storing the manufacture information having been validated and the history information, and for associating the manufacture information and history information with the unique identifier; and a reporting engine, integrated in the processor and being in communication with the central database, to report information from the central database on a user-interface of a remote device, for tracking and managing the asset from the remote device, based on the manufacture information and the history information.

2. The system according to claim 1, wherein the data importation module comprises a data input module for identifying a format of the manufacturer information received and for reading the manufacturer information based on the format.

3. The system according to claim 1 or 2, wherein the data importation module comprises a data parser for identifying a correspondence between the manufacturer information to be imported and fields of the central database.

4. The system according to any one of claims 1 to 3, wherein the data integrity rules are predefined.

5. The system according to any one of claims 1 to 4, wherein the data integrity rules comprise validation of the number of digits in a heat number against an expected number of digits.

6. The system according to any one of claims 1 to 5, wherein the data integrity rules comprise validation of a temperature reading against a predefined range of temperatures.

7. The system according to any one of claims 1 to 6, wherein the data integrity rules comprise validation of numeric and alphanumeric character requirements in a given pipe number

8. The system according to any one of claims 1 to 7, wherein the data integrity rules comprise validation of a wall thickness against a given range of wall thicknesses.

9. The system according to any one of claims 1 to 8, wherein the data integrity rules comprise validation of a coating thickness against a given range of coating thicknesses.

10. The system according to any one of claims 1 to 9, wherein the data integrity rules are defined based on an asset operator's requirements.

11. The system according to any one of claims 1 to 10, wherein the data integrity rules are defined based on regulatory requirements.

12. The system according to any one of claims 1 to 11, wherein the data importation module comprises an error processing module for processing an error output from the validation module.

13. The system according to any one of claims 1 to 12, further comprising an administration module, integrated in the processor, for administering user accounts and associated permissions to access the central database.

14. The system according to any one of claims 1 to 13, further comprising a tag reader being in communication with the database over a communication network for exchanging information with the database, the tag reader having a reading module for reading the identifier stored on the tag of each asset.

15. The system according to any one of claims 1 to 14, wherein the reporting engine is configured to provide a real-time accessibility to the remote device.

16. The system according to any one of claims 1 to 15, further comprising a plurality of the remote devices being further in communication with the database via the communication network.

17. The system according to claim 16, wherein the plurality of remote devices comprises at least one of: a ruggedized laptop computer; a tablet computer; a conventional computer; and a smart phone.

18. The system according to any one of claims 1 to 17, wherein the reporting engine comprises a data retrieval module for retrieving information from the database on the basis of a given unique identifier stored on an identification tag of an asset, the reporting engine further comprising an output module for outputting the report to one of the remote devices via the communication network.

19. The system according to any one of claims 1 to 18, further comprising a tag printer for printing a new identification tag.

20.
The system according to any one of claims 1 to 19, wherein the data importation module is in communication with the plurality of entities, each entity being selected from the group consisting of:
a transportation data source;
a storage yard data source;
a construction yard data source;
a pipe cutting data source;
a surveyor data source;
an installation data source including at least one of:
welding data;
x-ray data;
pipe cutting data;
pipe bend data;
coating data;
girth weld coating data;
pre-commissioning test data; and inspection data; and operations and maintenance data source including at least one of:
inline inspection data;
cathodic protection data;

pipe quality data;
visual inspections; and cut-out and replacement data.

21. A method for tracking and managing oil and gas infrastructure assets, the method comprising the steps of:
a) importing into a central database manufacture information on a given asset from a manufacturer data source, the importing step comprising validating the data to be imported based on data integrity rules;
b) associating in the central database, the manufacture information having been imported, to a unique identifier stored in an identification tag mounted on the asset;
c) storing in the central database, history information from a plurality of entities, during a lifecycle of the asset after manufacture and associating the history information to the unique identifier, in order to report information from the central database on a user-interface of a remote device, for tracking and managing the asset, from the remote device, based on the manufacture information and the history information.

22. The method according to claim 21, wherein the importing step (a) further comprises:
identifying a format of the manufacturer information received.

23. The method according to claim 22, wherein the importing step (a) further comprises:

parsing the manufacturer information based on the identified format in order to identify a correspondence between the manufacturer information to be imported and fields of the central database.

24. The method according to any one of claims 21 to 23, wherein the data integrity rules of the validating in step (a) are predefined.

25. The method according to any one of claims 21 to 24, wherein the data integrity rules of the validating in step (a) comprise validating the number of digits in a heat number against an expected number of digits.

26. The method according to any one of claims 21 to 25, wherein the data integrity rules of the validating in step (a) comprise validating a temperature reading against a predefined range of temperatures.

27. The method according to any one of claims 21 to 26, wherein the data integrity rules of the validating in step (a) comprise validating numeric and alphanumeric character requirements in a given pipe number.

28. The method according to any one of claims 21 to 27, wherein the data integrity rules of the validating in step (a) comprise validating a wall thickness against a given range of wall thicknesses.

29. The method according to any one of claims 21 to 28, wherein the data integrity rules of the validating in step (a) comprise validating a coating thickness against a given range of coating thicknesses.

30. The method according to any one of claims 21 to 29, wherein the data integrity rules of the validating in step (a) are defined based on an asset operator's requirements.

31. The method according to any one of claims 21 to 30, wherein the data integrity rules of the validating in step (a) are defined based on regulatory requirements.

32. The method according to any one of claims 21 to 31, wherein the importing step (a) further comprises after the validating step:
receiving an error output from the validating step;
processing the error output; and receiving data correction instructions.

33. The method according to any one of claims 21 to 32, wherein the importing of the manufacture information of step (a) comprises importing pipe mill information from a pipe mill.

34. The method according to claim 33, wherein the pipe mill information of step (a) comprises at least one of: tally data; mill run data; inspection result data;
and work order integration information.

35. The method according to claim 33 or 34, further comprising associating in the central database a new unique identifier stored on a corresponding pipe mill identification tag mounted on the asset at the pipe mill.

36. The method according to any one of claims 21 to 35, wherein the importing of the manufacture information of step (a) comprises importing coating plant information from a coating plant.

37. The method according to claim 36, wherein the coating plant information of step (a) comprises at least one of: tally data; inspection result data; and coating specification data.

38. The method according to claim 36 or 37, wherein the validating of step (a) further comprises validating the pipe mill information based on the manufacturer data stored in the database.

39. The method according to any one of claims 21 to 38, wherein one of the entities of step (c) is a transportation facility and the storing of history information of step (c) comprises storing transportation information.

40. The method according to claim 39, wherein the transportation information comprises at least one of: way bills data; bill of lading data; shipper data;
tracking subcontractor data; and receiving information.

41. The method according to claim 39 or 40, wherein storing of step (c) comprises storing the transportation information through batch processing.

42. The method according to any one of claims 21 to 41, wherein one of the entities of step (c) is a storage facility and the storing of history information of step (c) comprises storing storage information.

43. The method according to claim 42, wherein the storage information comprises at least one of: PO number; and vender ID.

44. The method according to claim 42 or 43, wherein storing of step (c) comprises storing the storage information through batch separation.

45. The method according to claim 42 or 43, wherein storing of step (c) comprises storing the storage information through electronic data interchange with ERPs.

46. The method according to any one of claims 21 to 45, wherein one of the entities of step (c) is a construction facility and the storing of history information of step (c) comprises storing construction yard information.

47. The method according to claim 46, wherein the construction yard information comprises at least one of: material testing reports; and asset location data.

48. The method according to claim 46 or 47, further comprising:

storing in the database shipping and receiving information related to the asset; and validating, at the construction facility, the shipping and receiving information.

49. The method according to any one of claims 21 to 48, wherein one of the entities of step (c) is a pipe cutting facility and the storing of history information of step (c) comprises storing pipe cutting information.

50. The method according to claim 49, wherein the pipe cutting information comprises at least one of: cut and joint information; X-ray testing data; and child and parent association data.

51. The method according to any one of claims 21 to 50, wherein one of the entities of step (c) is a pipe bending facility and the storing of historical information of step (c) comprises storing pipe bending information.

52. The method according to claim 51, wherein the pipe bending information comprises at least one of: bending specification information; and structural integrity impact information.

53. The method according to any one of claims 21 to 52, wherein one of the entities of step (c) is a surveyor entity and the storing of history information of step (c) comprises storing surveyor information.

54. The method according to claim 53, wherein the surveyor information comprises at least one of: pipe latitude, longitude, elevation; and integration with third-party mapping services.

55. The method according to any one of claims 21 to 54, wherein one of the entities of step (c) is an installation facility and the storing of history information of step (c) comprises storing installation information.

56. The method according to claim 55, wherein the installation information comprises at least one of: maintenance data; reporting options data; depth of buried pipe; preventative quality control measures taken; and maintenance related work information.

57. The method according to any one of claims 21 to 56, further comprising:
receiving a reporting request from the remote device, the request comprising the unique identifier of the asset;
retrieving the requested information from the database;
returning a report to the remote device, in response to the request, for presentation on the remote device; and the report comprising at least one of: manufacturer information and history information retrieved from the database.

58. The method according to claim 57, wherein the reporting request originates from a workspace accessed via the remote device based on login information from a user.

59. The method according to claim 58, wherein the login information comprises a user identifier associated to the user, and wherein the accessing step further comprises:
verifying a user permission based on the user identifier; and wherein the retrieving step comprises retrieving the requested information for which the user permission allow access to.

60. The method according to any one of claims 57 to 59, wherein the unique identifier of the receiving step originates from a reading of the identification tag of the asset, via a tag reader.

61. The method according to any one of claims 57 to 59, wherein the unique identifier of the receiving step originates from a user entry.

62. The method according to any one of claims 57 to 61, wherein the reporting request comprises a plurality of the unique identifiers associated to a plurality of corresponding one of the assets.

63. The method according to any one of claims 57 to 62, further comprising, sending the reporting request from the remote device.

64. The method according to claim 63, wherein the sending step and the retrieving step are executed in real-time.

65. The method according to any one of claims 21 to 64, further comprising:
providing the identification tag having the unique identifier stored thereon;
mounting the identification tag on the asset; and if the tagging process is not completed:
i) generating a new unique identifier in the database;
ii) providing a new identification tag having the new unique identifier stored thereon;
iii) mounting the new identification tag on the asset; and iv) if the tagging process is not completed, repeating steps (i) to (iii).

66. The method according to any one of claims 21 to 65, further comprising:
storing, in the database, operational procedures relative to an asset;
generating a procedure message for presenting the operational procedures on the user-interface of the remote device;

receiving status information from the remote device, relative to the operational procedures; and associating a completion status in the database, to each of the operational procedures based on the status information received.

67.
The method according to claim 66, wherein the completion status represents a completed task or a non-completed task, the method further comprising:
if one of the procedure is identified as having a status representing a non-completed task, generating an exception report identifying the asset and the procedure.