Registry web services have proven to be a valuable resource for access to Coordinate Reference Systems (CRS) and associated units of measure, for exploration companies. While there are no statistics, it is quite likely that such systems have saved significant dollars through the reduction of errors in CRS parameters and hence in the placement of drilling rigs and bore holes.
Registry services offer global access to the CRS information that can be immediately and automatically consumed by tools like Blue Marble’s Geographic Calculator and ESRI ArcGIS Server.
Registry services may soon be deployed in another domain, and that is for information on pipelines, including the aggregation of pipeline design, construction, and inspection information over the pipeline’s lifetime. As in the case of CRS data, such registries will exploit emerging standards for pipeline information, and serve to reduce errors in decision-making arising from incomplete or inaccurate data.
A registry service is a web service based on the OGC CSW-ebRIM data model and supporting web-service interfaces bearing the same name. Since it is a web service with open standard interfaces and content, it is suitable for the “registration” of information from multiple sources (e.g. pipeline component manufacturers), and for the search and processing of this information (e.g. pipeline operator makes a decision about inspection frequency and type).
Rapidly create information models
The registry service data model (CSW-ebRIM) enables the rapid creation of application- specific information models incorporating typed objects (objects with properties), classification schemes (taxonomies), associations (relationships), and logical collections. This might for example provide a pipeline component object, or types of pipeline components, and then express classifications (e.g. pipe type, station type, product type, rectifier type), associations (e.g. component connectivity), and collections (e.g. a pipeline is a collection of pipe segments, stations, pumping systems, corrosion protection systems etc.).
Application-specific information models are entirely portable across registry services and can be loaded into a registry by a simple XML transaction.
Any object placed in the registry is automatically assigned a globally unique identifier. In a registry of component types, this then provides a unique identifier for every type of component that may be used in the deployment of a pipeline.
Since the registry is also geographic (i.e. every data object can have one or more location properties), one can easily see the emergence of registries of pipeline component instances, the instances referring to the types in the component types registry. Again each such instance is assigned a globally unique identifier, the identifier now referring to a particular installed component (e.g. a pipe segment in the ground).
Such registries can be queried by pipeline operators and service providers alike, to obtain the requisite identifier, using geography, connectivity and other criteria.
Measurements, inspections, and other records generated by the service provider are then attached to the component instance global identifier and “sent” to the specific registry as a CSW-ebRIM transaction. Such transactions can include property updates, and unstructured documents (e.g. word document, images etc.).
The registry stores these attachments as repository items and links them to the appropriate registry object. If the service provider desires, the actual document can be maintained locally on their system, and a link generated to reference the resource from the registry. This link object can be associated to other components, classified etc., as if it were in the registry itself.
User definable life cycle states
Registries also support user-definable life cycle states for any registered object. In the component types registry, this might reflect the current state of that object (e.g. planned, designed, in production, discontinued), while for the instance registries this could reflect other possible states such as ordered, manufactured, delivered, installed, operating, discontinued, or removed.
All manner of information may be attached to an instance in a selected pipeline instance registry, including inspections, measurements, design notes, field construction notes, photographs, and analysis reports (e.g. maximum pressure calculations). This information is attached using open-standard registry transactions. This can clearly include incident reports and incident classification (explosion, fire, gas leak, oil spill) and incident properties (number of deaths, number of injuries, property damage, environmental damage, oil spilled).
Most registry services support some form of automated notification based on changes in the registry data. For example, when a service provider registers an inspection report, an e-mail notification can be automatically generated to the pipeline operator. Such notification can contain extracts from the registry objects or simply references to the appropriate globally unique identifiers in the impacted registries.
Operations companies can thus always stay in sync with any changes to the inforpipeline equipment & maintenance Registry services aid in reduction of reference errors for pipelines mation about their assets, or about new components that might be deployed in future pipeline systems.
The development of new pipelines such as Keystone XL, and the Northern Gateway are major topics in the news, with strong proponents, and equally strong opposition. Pipeline component type and instance registries can help start these systems on the right footing, with proper data management. This can reduce the risk of future problems, and help gain acceptance.
Existing pipelines, of which there are some 300,000 miles in North America, represent a serious risk for both the operating companies and nearby citizens.
Aging pipeline infrastructure can benefit
Much of the pipeline infrastructure was built prior to 1950, and lacks the information on design, component specifications, and current state information essential to decision making. As this information gap is filled by service providers (e.g. engineering drawing review and digitisation, pipeline physical inspection and internal measurements), it is essential that this information be provided to pipeline operators in an open standard manner so as to speed the process of data acquisition and integration, reduce the labour cost for operators and service providers alike, and reduce the inevitable errors caused by data translation, and manual copying.
Registries can play a significant role in providing open interfaces for acquisition and integration of this information, and thus make a significant contribution to the reduction of future incidents.