The 2013 Asia and Australia PCA Forum and Members meeting will be held on the 21st and 22nd Oct 2013 at the Intercontinental Hotel in Kuala Lumpur, Malaysia.

The Asia and Australia PCA Forum and Members meeting will feature presentations and discussion from Owner/Operators, EPC Companies, Standard Bodies & Representatives, Software Vendors, System Integrators, Business Analyst, Engineering Consultants, Educational Institutions and Industry Associations identifying key business requirements and solutions leveraging on open supplier’s neutral standards, with a focus on benefits of using ISO 15926 in coordinated fashion.

Conference Organizer

POSC Caesar Association (PCA) is a non-profit global-standardization member organization promoting the development of open specifications to be used as standards for enabling the interoperability of data, software and related matters. PCA initiated ISO 15926 “Integration of life-cycle data for process plants including oil and gas production facilities” and is committed to its maintenance and enhancement.

Conference Hosts

The conference is being hosted by PETRONAS and the Malaysian Oil and Gas Services council.

PETRONAS was incorporated on 17 August 1974 as the national oil company of Malaysia, vested with the entire ownership and control of the petroleum resources in the country. It has since grown from merely being the manager and regulator of Malaysia’s upstream sector into a fully integrated oil and gas corporation, ranked among the FORTUNE Global 500® largest corporations in the world.

The Malaysian Oil & Gas Services Council or MOGSC was formed on 1st December 2003, as an initiative to establish an association driven entity and to promote the services sector of the Malaysian Oil & Gas Industry. MOGSC is now the premier business forum representing the interests of Oil & Gas service providers with membership of almost 400 companies providing comprehensive coverage to all services sector within the industry.

 Conference Theme

This year the conference focuses on the challenges facing the industry related to Information and Application Interoperability and how ISO 15926 deployment and/or utilization lead to the realization of Integrated Operations. The 2013 PCA Forum and Member Meeting offers participants the opportunity to share their success stories and lesson learnt in relation to iRING/ISO15926, Interoperability or Integrated Operations.

Call for Papers

The PCA is formally calling for papers and panel discussion proposals from Oil and Gas Industry participants in line with the conference theme “Interoperability Challenges in Integrated Operation Implementation”.

Proposals should address one or more of the following topics:

• Modeling
  • Creation of stable, scalable and commercially-viable data
  • ISO15926 reference data system and associated services
• Drilling and Completion
  • Analyzing, developing and testing an autonomous and semi-automated drilling control system
  • Standardizing communications protocols for drilling control systems
  • Framework for advanced software agents
• Operation and Maintenance
  • Develop and publish input which properly incorporates the Operations and Maintenance oriented concepts and methods established by the Open O&M initiative and ISO standards
• Instrumentation and Control
  • Classes and relationships proposed for PCA standardization by the EqHub project
• Production and Reservoir
  • Establish and maintain correct and reliable reference data related to petroleum production and reservoir management.
• Geometry
  • Representation of ISO 15926 Part 3 Geometry Reference Data using Part 7 Template Methodology
  • Geometry Reference Data
• IT Architecture
  •  IT and Data Architecture
  • Data Governance

 Deadlines

• Submission of Abstract: 15th Jul 2013
• Acceptance Notification: 29th Jul 2013
• Submission of Full Papers: 19th Aug 2013
• Submission of Slides: 20thSep 2013

Submission Requirements

• All papers and presentations will be evaluated in a standard blind peer review.
• Full Paper (individual or multi-author)
• Submit abstract of 600-800 words.

Submitted papers/proposals to the following email address: pca2013kl@outlook.com

The 2013 Asia and Australia PCA Forum and Member Meeting will be another productive and memorable event for the industry.

The post 2013 Asia and Australia PCA Forum appeared first on iRINGToday.

Anatoly discusses why iRING/ISO 15926 technology is the best data integration solution for the oil and gas industry.

The post Best data integration technology appeared first on iRINGToday.

I-S-O 1-5 what?

The rest of the community, being mostly volunteers with day jobs and families to manage (which category includes your humble scribbler here) went blithely about their business. If you had done an MRI on our heads while we were working you would have found “ISO 15926” had left the part of our brains devoted to remembering strings of numbers and migrated to the part devoted to remembering names. Fifteen-nine-twenty-six was what it was. It didn’t really matter what anyone else called it, our work was still the same.

Well, at the recent Fiatech conference in San Antonio we decided to get serious and all call it the same thing. So iRING it is. (The formal name of the standard is, and will remain, ISO 15926. So in a technical conversation that is specifically about the standard itself the formal name is proper.)

However, there remains a bit of confusion around the new name because some software tools being developed also use it. A bit of background is in order.

The name iRING was coined around the beginning of 2009, give or take a a bit. At the time there was some controversy about how ISO 15926 could be implemented. A group of intrepid folks took it upon themselves to attempt to use what they called the “full standard of ISO 15926″ and see where it lead them. Of course, if you take on a large task you need a catchy name and what would be better than ISO 15926 Realtime Interoperability Network Grid, or just iRING. (The name is a subtle reference to the RDL–if you read a previous post, Understanding the ISO 15926 RDL, you will get the drift.) The result of this work is a set of open source tools that everyone can use called iRINGTools Open Source Software. Of course.

Meanwhile, back at the ranch, ISO 15926 was garnering more and more attention. The early adopters of iRING (and indeed, any new technology) tend to be people who enjoy complexity and a complex name is just part of the charm. But ISO 15926 is now starting to attract people with more of a “cut the baloney and show me what you can do” attitude. People for whom a complex name composed of random numbers is a barrier. As it turns out, the name iRING seemed to stick. (Perhaps it’s an example of the “Kleenex Effect”, named after the first brand of soft facial tissue that was widely advertised.)

So where do we stand?

First, iRING is the umbrella name we will all use when referring to anything that is related to ISO 15926. All of us had some documents in process that still referred to ISO 15926 in the general sense and some of these are still working their way through the system. Please be patient. We promise (cross our hearts!) to start using the name iRING on all new stuff.

Second, iRINGTools Open Source Software is the name of a particular set of tools for implementing ISO 15926. There are others that have just as legitimate a claim to the name iRING. Actually, there are quite a few others and in an upcoming article we will describe three that were used in a public demonstration.

But don’t make the mistake of spelling it “Iring”. If you do you might just as well put a “kick me” sticky note on your back!

The post What’s the Difference Between iRING and iRING? appeared first on iRINGToday.

BIM is a great idea. The idea that the whole business lifecycle for any built-environment engineered-asset, should work collaboratively around a “model” of the asset. The most obvious “sexy” bit of that model is the 3D Model (and assorted 4D, 5D, 6D dynamic variants) and both engineers and owners appreciate that seductive view. But that view is of course, a window on the more complete information model of the asset and all the business processes involved, from inception, through design, engineering, approvals and construction to operation and maintenance, and beyond, encompassing every aspect from basic functionality to sustainability in the widest sense. It really is a great idea.

BIM is not an entirely new idea, of course. Evolving from greater adoption and more intelligent use of 3D modelling in buildings generally and, in complex facilities typical in the Energy and Process business, the wider information model supporting both handovers and multi-discipline collaborative working and configuration management throughout the lifecycle, has been evolving for over 2 decades. As with the BIM community the drive started with customer “handover” in the big-bang sense, but evolved to staged “Soft Landings” handover, and recognition that sharing the model at any stage in the lifecycle has immense value for those doing the sharing. It’s an idea whose time has thoroughly come.

The convergence of ideas and technologies is so complete, that quite frankly this ceased to be a technology problem some time ago. Clearly there are technology choices to be made, but the problem is not shortage of options, rather the opposite. The number of human and machine interactions possible with the model and its information is already mind-boggling from design development, through procurement, in the field during construction, and throughout the asset ownership lifecycle, through integrated facility and maintenance operations, local and remote. You name it, you’ve probably already seen it, and the last thing you want to do is back a technology loser.

So the issue now is not technology per se, but business architecture. How to re-engineer the asset business to take advantage of the possibilities. What are the key business components and how should they be connected given the availability of such a model? At one end of the scale it’s about contracting cultures and organisational responsibilities for information, at the other end it’s about “big data” and the qualities of how each bit is modelled and managed.

iRING addresses one very specific enabling component of the business architecture conundrum. How to separate – maintain and de-risk independence and neutrality between – the business processes, the asset and application technologies and the value of the information content. How iRING achieves this is described here, but the essence is the ability to share reference data, from local “master data” to global standard terminology in a way that is both semantically rich (unambiguous) and independent of the particular business processes and your choices of applications and technologies.

iRING supports and is entirely complementary to your BIM vision.

The post iRING and BIM – What a team. appeared first on iRINGToday.

In Phase 1 the JORD Mapping Methodology and Compliance Specification were finalized and users can now publish Reference Data Library (RDL) references resolvable over the internet and semantic-web technologies – a facility known as an “EndPoint”. This final Phase 1 version also supports “Sandboxes”, where users may immediately create, use and publish their own interim reference data extensions, in advance of the PCA and ISO validation processes.

The Business Benefits of Industry-wide Interoperability

The business value in achieving flexible interoperability between business-units, supply chain partners and systems, over long multi-project, multi-asset, multi-business life-cycles are well understood. And everybody agrees that achieving these benefits has a strong dependency on standardization across systems, across information and across technologies, these include:

• Direct-cost-and-time-savings in reducing effort in transferring, mapping and in simply finding & accessing information necessary to do your business.
• Risk-and-cost-reductions in the quality and ambiguity of information which otherwise lead to sub-optimal business operations, failure to satisfy regulators or, in the worst case, loss of health, safety & environmental integrity.
• Freedom-and-opportunity to take advantage of new collaborative business processes, flexible business partnering, new technology applications and different subcontracting arrangements across your evolving business operations and supply-chains in geographically distributed locations, which may be remote & inhospitable.

How do JORD and iRING Reference Data achieve these benefits?

Business Processes & Applications; Data & Information; and Implementation Technologies must each be standardized independently wherever possible, if the flexible benefits are to be realized. iRING is built on this component architecture, focussing on standardization of information definitions (models and semantics) independent of particular business uses, and neutral with respect to implementation technologies.

A key feature of iRING is that information definitions are handled as shared Reference Data; reference data that is itself accessed and managed independently of your business information and its implementations, and indeed independently of the many possible standards and catalogues that may define that information.

iRING Reference Data supports interoperability and sharing of information definitions between different information standards as well as between different businesses and technologies.

Crucially, because it is unthinkable for multiple whole industries to rely on a single reference data service provider for all critical business lifecycles, a key feature of the iRING RDS architecture is that it supports multiple federated reference data systems and service providers. And, being entirely technology neutral, it can also exploit the latest standard “semantic web” technologies without imposing any dependency other than the capability to use internet protocols to read any reference information resource.

In order to exploit this approach to enhance existing PCA RDS Operations, the JORD Project is establishing a core set of services and capabilities, which enable the evolution, management and validation of compliant use of reference data not only by your business directly, but also by complementary and competing providers of value-added content, systems and services to your wider business operations and supply chains.

Phase 1 successes included delivering the following:

JORD Phase 1 focussed on achieving a number of technical enhancements to the existing PCA RDS Operation, essential to enabling the full scalable and sustainable aims of Phase 2.

Compliance Methodology

In Phase 1 the key compliance deliverables were the JORD Mapping Methodology and the JORD Compliance Specification. Final Phase 1 versions were both delivered after a series of reviews and updates of existing resources.

The JORD Compliance Specification provides a clear statement of what it means to comply with the JORD core of iRING, whilst recognising that different levels of compliance may be achieved in several pragmatic and independent steps.

The JORD Mapping Methodology provides non-ISO15926-expert, business domain specialists with a reliable and repeatable method of representing their business information in iRING formats and reference data which ultimately guarantee compliance with the formal requirements of the ISO15926 standard, according to the levels of the JORD Compliance Specification. The methodology uses “Template Signature Patterns” expressed in business domain terms which hide the business user from unnecessary exposure to the generic modelling terminology of the standard itself. In doing so the Methodology opens up many more business workfronts to exploiting the iRING approach avoiding dependency on a few scarce iRING technical specialists.

The JORD ID Specification has also captured requirements for truly persistent naming and identification of reference data fundamental to its sustainable use and change-management over long life-cycles and wide federation.

Full use of both the Compliance Specification and the Mapping Methodology still depend on the evolution of additional Template Signature Patterns in the core Reference Data Library and on creation of new operational processes for validation. Already however users are developing their use of the methodology and suppliers are applying the Compliance Specification Checklist to their implementations.

RDL Publishing “EndPoint”

One of the key challenges to the existing PCA RDS was to provide supportable publishing of Reference Data Library (RDL) content as references resolvable over the internet and semantic-web technologies – a facility known as an “EndPoint”. Two generations of EndPoint implementation were achieved in Phase 1, the second version of which is implemented in a commercially hosted environment giving flexibility and independence in how future enhancements are managed by PCA. This final Phase 1 version also supports “Sandboxes”, where users and interest groups may immediately create and use their own interim reference data extensions, in advance of the PCA and ISO validation processes.

The Phase 1 EndPoint implementation does not yet support the fully scalable and sustainable business capability, but is already enabling new supportable enhancements to the RDL web publishing and quality management capabilities.

With Phase 1 having focussed on specific technical enhancements, the Phase 2 focus now switches to the scalable infrastructure and sustainable business operational aspects of both the PCA RDS scope and user business cases.

 Get Involved Now to make Interoperability a Reality for the Industry

JORD continues to deliver the core needs of the scalable and sustainable PCA RDS operation and requires additional funding. Interested parties should enquire for a participation package including the model participation contract (detailed fees, terms and specific benefits to sponsors and subscribers).

For additional information, or to express interest please see contact:

• Nils Sandsmark – PCA General Manager nils.sandsmark@posccaesar.org / www.posccaesar.org
• Ray Topping – Fiatech Director topping@fiatech.org / www.fiatech.org
• Ian Glendinning – JORD Business Manager – ian@glencois.com / www.posccaesar.org/wiki/FiatechJord

The post JORD Phase 1 Complete appeared first on iRINGToday.

Goal – Remove Ambiguity

When you model information for use with ISO 15926, your goal is to capture the full meaning of the information so that when your computer talks to my computer, my computer will understand the meaning of your information without requiring any of the background knowledge that humans have. To repeat what we have said many times, you want to drive the ambiguity out of your information. You want to take the implied information, that is, everything that “everybody just knows”, and make it explicit.

For an example, imagine you are trying to explain to my computer what “Maximum Operating Pressure” means on a Line List or P&ID.

Sensing a trick question you might start by asking yourself what Maximum Operating Pressure really is. Your mental image might be a pressure gauge attached to a piece of pipe, with something like “Normal Operating Pressure” being the point on the dial that the engineer assumed the pipeline would be running at most of the time. You might imagine that “Maximum Operating Pressure” to be a red line on the dial past which you should start running. From that line of reasoning you might conclude Maximum Operating Pressure is a property of the Pipeline.

Computer! Maximum Operating Pressure is a property of the Pipeline!

On the surface, that seems pretty good, especially after thinking about it extra hard. But if my computer were to attach a pressure gauge to the pipe based on that explanation, working literally from what you said it would weld the pressure gauge directly on to the side of the pipe.

“Of course!” you say “That’s what it should do!”

But look carefully at what I said. I said that the computer would weld the pressure gauge directly on to the side of the pipe; I did not say that it would cut a small hole first.

“What?” you reply. “You’d have to be pretty stupid to do that.”

Well, no one ever accused a computer of being smart.

“Yes”, you try again, “but everyone knows you have to cut a little hole first.”

True, every person knows. But a computer isn’t a person. It has no experience. It will only do what you’ve told it to do.

“But”, not giving up yet, you ask “what do you think you are measuring here anyway? The pressure of the steel the pipe is made from?”

Well, that’s actually what you said, “Maximum Operating Pressure is a property of the Pipeline.”

We could carry on like this and perhaps turn it into a regular Monty Python skit, but I think you get the drift.

If you have never done this kind of information modeling before you may be offended by the apparent silliness of this example. Of course we are measuring the pressure of the fluid (not the pressure of the steel the pipe is made of), and of course the fluid is inside the pipe (therefore we have to cut a small hole for the pressure gauge). People in the industry know this instinctively, but you have to spell it out in detail when you are talking to a computer.

And so we can see the point of information modeling. We are forcing ourselves to explain just exactly what we mean; we want to remove ambiguity and embed the meaning of the data into the data itself so that even machines will understand.

First: Identify all of the “things” we are dealing with

To do this we ask a pair of questions repeatedly until we have found enough “things” to properly identify the data we are exchanging. (To make it easier the diagram below shows all the “things” we need to consider.) We consider each “thing” in turn. 

Maximum Operating Pressure

Q1.  “What is the property in focus?”

A1.  Of course, it is “Maximum Operating Pressure”.

Q2.   “To which object does the property in question pertain?”

We might be tempted to answer “Why, the line number, of course.” But we have a problem here because all of the properties of a line number do not always stay constant for the entire length of the line.

Consider a cooling water header that starts at a large diameter and gradually reduces its diameter as branch lines take water away. Each time water leaves the header and each time the diameter changes the velocity and pressure of the water change.

Process engineers have a construct to manage this which they call the “Stream”. The stream holds all the properties required in process design. When any of the properties change, the stream, or “stream ID”, changes.

A2.  Maximum Operating Pressure is a property of the Stream.

Stream

Now we move our focus to the next “thing” and ask the two questions again (slightly modified because the next “thing” is not a property but an object itself.)

Q1.  “What is the object in focus?”

A1.  The “Stream”.

Q2.  “To which object is the object in question related?”

Again, we might be tempted to answer “The line number. What else can it be?” But we have the same problem here as before, in that not all of the properties required for mechanical design are properties of the stream (for instance, process engineers are not usually concerned with the allowable tensile strength of the material the pipe is made from), and not all of the mechanical engineering properties remain constant for the entire length of the line. The construct used by mechanical engineers is “Line Segment”. When any of the mechanical engineering properties change, the line segment, or “segment ID” changes.

A2.  The Stream is related to the Line Segment.

Line

Again, we move our focus to the next “thing”.

Q1.  “What is the object in focus?”

A1.  The “Line Segment”.

Q2.  “To which object is the object in question related?”

A2.  The Line Segment is related to “Line”.

Carry on or Stop?

We can carry on here to any arbitrary point since, in reality, everything is connected to everything. (For instance, the line in our example might be part of the cooling water system, which is connected to the cooling water pumps, which might be part of the Utilities unit, which is part of a particular process plant, which is … eventually connected to Life, the Universe, and Everything.) However, if our purpose is to define just what we mean by “Maximum Operating Pressure” we can stop here.

Second: Identify all of the relationships

In this step we identify the relationships between all of the “things”. (The manner of choosing the correct relationship is not particularly difficult, but is beyond the scope of this blog, so again, we give the answers in the diagram below.)

To show you how this removes ambiguity in an exchange, let us go back to the initial example where you were trying to send my computer a line list. To do this you would send a stream of data which my computer would assemble into a coherent document.

At one point you would be sending the maximum operating pressure of a line.

You:  “Computer! I want to send you a Maximum Operating Pressure.”

Computer:  “What is this Maximum Operating Pressure of which you speak?”

You:  “The Maximum Operating Pressure I am going to send you is a property of the object Stream, which is contained within the object Line Segment, which itself is a part of the object Line.”

Computer:  “Aha! That Maximum Operating Pressure! Send it to me!”

You:  “42”.

The bottom of the Rabbit Hole

This is by no means the bottom of the rabbit hole; it goes quite a bit deeper than this. For instance, we still have to select the proper “class” names for the objects and properties, and select the proper “templates” for the relationships, and of course, teach our software how to transform our data in to and out of the ISO 15926 representation. But it does show how the meaning of the data is embedded into the data itself.

Using the ISO 15926 Representation of your Data

When you use ISO 15926 to represent your data you can literally broadcast it to the world and other, similarly-equipped software will pick out of the data stream just what it needs.

Example: Instrument Data Item.

You could send an entire P&ID and all the associated data to an instrument vendor and let the vendor’s software pick out just the bits it needs to select the correct instruments from the catalogue.

Vendor’s Computer (examining the data dump you just sent it) “We are selecting the correct model for pressure transmitter 1234 located on line 5678. Let’s see…we need to find Maximum Operating Pressure that is a property of Stream which is contained in Line Segment which is part of Line 5678. Aha! There it is!”

We would probably not send an entire data dump to a vendor that just needed one data value, but in the real world the vendor would probably need more than one. A better solution would be to expose the P&ID data on the Internet and let the vendor’s software come in and make a query—there would be no need to send any data to anyone.

Example: Advanced Analytics

Currently, when someone, say, a plant’s efficiency engineer, wanted to use a project’s data he would have to request certain data items to be extracted, from possibly multiple sources, and be put into a particular form. This adds considerably to the “friction” of getting things done. In the ISO 15926 world the owner would simply expose the project data to the engineer. Because the ISO 15926 representation of the data includes all of the relationships (see above – Life, the Universe, and Everything), the engineer would be able to follow all the links to whatever he needed to see. For instance he would have the ability to navigate from a start point into the data on a pipeline that allows him to walk to the segment, to the stream, and then continue to the cases of the stream, specs, or whatever. Or from the pipeline to a valve on the pipeline to its purchase order and on to its invoice.

And when we add in mobility, the value could really explode because we would be able to leverage explicit links in a large set of endpoints of project and manufacturing data.

Where to from Here?

Where you, dear reader, go next depends on your perceived role in an information exchange. In a previous post we compared information modeling on an information exchange project to stress analysis in plant design. In plant design we have developed a three-tier structure for stress analysis; finite element modeler, stress engineer, and piping designer. In information modeling the first two comparable levels would be something like Part 2 Guru and ISO 15926 Modeling Expert. The third level, Subject Matter Expert, could be you. The basic rules for information modeling are accessible enough that interested industry professionals can do most of the modeling for their subject area.

Find out More

The best way to find out how to implement ISO 15926 is to get involved in one of the projects sponsored by Fiatech or the POSC Caesar Association (PCA). There is always a half dozen or so going on at any one time dealing with design and implementation issues for various parts of ISO 15926. Take a look at their websites.

• http://fiatech.org/

• https://www.posccaesar.org/

If you would like to read more about ISO 15926 download An Introduction to ISO 15926 from the sidebar.

The post Information Modeling for ISO 15926 appeared first on iRINGToday.

The direct forebears of ISO 15926 started life in the early 1980′s, and it was published under its own name in the late 1990′s. But if we recast the question as “When did people start solving information exchange problems so they can make things better” we can go back quite a ways further, perhaps even to a caveman learning the words of a neighboring tribe in order to figure out how they  knap flint to make these new-fangled spears.

We won’t go back that far.

Information Exchange before the Industrial Revolution

The National Institute of Science and Technology—in its publication STEP, The Grand Experience—starts before the Industrial Revolution with a description of what we would today call a machinist, carefully measuring the prototype of a part while making a duplicate. This seems like a good place, so we’ll start there too.

If only I could tell the craftsmen what I really want

Imagine the happy dilemma of a 17th century inventor who has sold more of his machines than he can make himself. He needs to hire some craftsmen. But to do that he needs a way tell them how to make the parts so that they will more-or-less fit together when he gets them back.

This is an information exchange problem, but the inventor will probably not express it as: “If only we knew how to make engineering drawings using ISO 10303-224 Geometric Dimensioning and Tolerancing.” His only option is to make a number of prototypes of the parts he needs and distribute them to the craftsmen.

If only we had a better way to tell the craftsmen which dimensions are critical

In our example here, the inventor will probably know all of the craftsmen personally. He can explain the function of each part and it will be obvious to everyone which dimensions are critical. But notice that this requires direct contact—he can only deal with people he knows and can talk to.

Again, this is an information exchange issue. This was largely solved over the next couple hundred years as the use of engineering drawings became commonplace. Standard methods of showing tolerancing developed until now one can source mating parts from around the world and have them all fit together perfectly when they are delivered.

If only we had something more accurate than drafting by hand

The first systems we would call CAD were written in the early 1960s in universities, with commercial systems appearing a few years later. The early commercial CAD systems were developed by computer manufacturers as tools to increase hardware sales, and by large organizations, such as automotive and aerospace companies, to assist their engineers in complex calculations.

In this I have some personal experience. One of my first jobs was in the engineering department at a fertilizer plant corkscrewing pipe the shortest distance between two points across 3D space. We wanted to give the pipefitters detailed instructions, in the form of “spool drawings”, showing how to fabricate the pieces of pipe so they would fit perfectly during a shutdown. This is an information exchange problem but we didn’t express it as “I wish we had a Whiz-O-Matic 3D CAD system,” all we wanted for Christmas was an electronic calculator that did sixteenths of an inch.

To make our views and projections, the state of the art was a new scale in the drafting machine (so there were no nicks), an expensive German compass (which we kept locked in a velvet-lined box) and a 9H pencil, as hard as iron and sharp enough to kill zombies. (Hey—What an idea! Planet Draftsmen: The Zombies Return. I wonder if Robert Rodriguez reads these kinds of blogs?)

Nowadays we model things in 3D and then extract them to drawings. If the systems are configured correctly we don’t even have to check them.

If only we could move drawings between CAD systems without redrawing them

By the 1970′s, there were a number of competing CAD systems, all with proprietary file formats, with the resulting inability to exchange drawings. At that time, even within a single organization, different manufacturing processes used different software that was not designed to communicate with each other. This meant that when drawings were sent along the fabrication chain, information had to be re-entered at every step. We, as an industry, soon grew tired of this. With a push from a major U.S. customer in late 1979 all of the major players were soon cooperating to create CAD exchange standards.

The same thing played out around the world and within a few years there were several CAD exchange standards in use. Today CAD exchange has evolved to the point that the major CAD software applications can open each other’s drawings as a matter of course.

If only we could keep the intelligence behind the drawings

When the only thing that needs to be exchanged is the graphics, CAD translation works reasonably well. But in a manufacturing environment the important part is the machine tool instructions. What appears to be a drawing is often only the human interface. In these situations, giving the “drawing” to a business partner using a CAD translator tool would lose almost all of the value.

To fill this need came the Standard for Exchange of Product Data, or STEP, which was eventually published as ISO 10303. It is a standard way of representing the features of a part in a machine-readable format. As a “STEP Model” moves down the supply chain, each production process reads the standard representation and converts it to its own instructions. For instance, a milling machine sees a 20mm diameter hole, selects the correct drill bit, and drills the hole. A CAD application, reading the same representation, renders the hole as a circle on a drawing.

The system works well in the manufacturing industry and parts of ISO 10303 are widely used today.

If only we didn’t have to use such a large data model

When we tried to adapt the principles of STEP to the process industry, we found that it just wasn’t practical. The STEP approach attempted to define all of the features of every product and assemble them into a large data model that covered everything. This is fine where the lifetime of a product is measured in years, but the life of a processing plant is measured in decades. There are just too many changes over the life of such a facility for a large data model to keep up. The solution was to separate the large data model into a more generic data model, consisting of smaller reusable pieces, and a reference library, consisting of the definitions of terms. (The ISO 15926 Reference Data Library was the subject of a previous post.)

This approach was first proposed in the mid 1990′s and was used in several world class projects over the next five or six years. The generic data model was published as ISO 15926-2 (or just Part 2), and the reference library was published as ISO 15926-4 (or just Part 4).

If only we all used the same reference library

Although Part 2 and Part 4 are designed to work together and were published within a few years of each other, commercial tools using Part 4 matured faster. In the beginning, Part 4 was essentially just a list of terms everyone agreed to use. A small industry sprang up using this “dictionary” approach to exchange information. Basically, instead of mapping two databases directly together, each is mapped to terms in the common reference library. This still requires a significant effort the first time, but once done the information can be reused at almost no cost. Today many information exchange projects are executed this way.

If only mapping were easier

A “dictionary” approach to information exchange is fine for a large payload. There is a large effort required to do the initial mapping, but if there is enough information to be exchanged it is worth it. But there is a continuum between something like the entire contents of a plant model (which might warrant the effort) all the way down to one or two data values on a single data sheet from an obscure supplier (which probably does not.) Between the two extremes are a great many opportunities for automated information exchange but that do not, individually, warrant such a mapping effort. To borrow a term from Chris Anderson, there is a long tail in information exchange. Moving the economic threshold of machine-to-machine information exchange toward the tail is the cutting edge of ISO 15926.

There are many initiatives that will have the effect of moving this threshold, but two that appear to have short term promise involve making mapping easier and more reliable.

• Reference Data Service

A minimum requirement for full-compliance ISO 15926 information exchange is that all parties to the exchange have access to the same reference data library (RDL) in real time. The Joint Operational Reference Data (JORD) project is developing an extensible, industrial-strength reference data service that will standardize the definition of terms across many industries.

• Template Mapping Methodology

When we map databases to ISO 15926 there are still some decisions to be made. This means that if two people independently map two databases to ISO 15926 we can still not guarantee that the two databases will be able to talk to each other (think: a French Canadian speaking English to a Cockney.) The template mapping methodology being developed jointly by JORD and the ISO 15926 Information Patterns (IIP) project will standardize the process of mapping by using using Part 7 to map relationships and objects together instead of database columns. This accomplishes the dual goal of making mapping easier and more consistent.

How can you call ISO 15926 a success when it’s still in development?

This boils down to whether you perceive the cup as being half full or half empty. People, including you and me, are never satisfied. (This is not a bad thing.) But if you look at our needs in engineering information exchange over the years (reread the headings in this post) you will notice that they’ve been met. It’s just that as soon as one need is met we come up with another “If only we had…”—the cup keeps getting bigger.

ISO 15926 developed logically, one step at a time, from an increasing need to exchange information faster and more reliably. The theoretical basis for ISO 15926 was mostly complete by the early 2000′s. Parts of it have been used on world-class projects and have saved real money.

Many organizations are participating in the continuing development of ISO 15926 and they will reap the biggest rewards. There is room for more!

Footnote:

This post borrows heavily from An Introduction to ISO 15926, available as a free download from the sidebar. For more information on the history of ISO 15926, see chapter 2.

The post ISO 15926 – A Decades-long Overnight Success appeared first on iRINGToday.

Fiatech’s Technology Conference & Showcase is held each spring and is open to the public.

The 2013 event will take place March 25-27 at the J.W. Marriott San Antonio in Texas. Tom Hannigan, President, Zachry Nuclear will serve as chair and Barbara Migl, Engineering Information Management Technology Leader, The Dow Chemical Company will serve as vice chair of the event.

Presentation proposals are being solicited in NOW. Registration will also open in December.

The post Fiatech Technology Conference – March 25-27 appeared first on iRINGToday.

The PCA Geometry Special Interest Group (SIG) team has released draft documents that provide the details of the ISO 15926 Part 7 Templates to be used for Geometry exchange. The initial focus is on 2D geometry. The Geometry SIG team is seeking comment from the broader ISO 15926 community, and implementers who are interested in Geometry Reference Data.

The two documents to be reviewed are Details of the ISO 15926 templates used for Geometry exchange and Geometry Template Signatures in a spreadsheet format.

The Geometry SIG is requesting timely comment on these documents with a deadline of December 5, 2012.

To comment on these documents please go here:  Geometry SIG discussion forum at 15926.org.

The Geometry SIG team continues to collaborate with the IIP, Proteus, and the JORD teams to finalize the templates required for the complete P&ID representation and will move on to 3D geometry for process plants in the next phase.

Finally, the Geometry SIG team welcomes more participation, please contact Manoj Dharwadkar (Manoj.Dharwadkar@bentley.com), Geometry SIG Chair, if you are interested.

The post Geometry Exchange – Open-for-Comment appeared first on iRINGToday.

While the latest version is 2.04 and the installation guide is still 2.03, there is still sufficient guidance to ensure a smooth installation.

Or so I thought …. Having recently set up a 2.04 server on a clean Windows 2008 Server and connected this to an eB instance for some testing, this went smoothly and I basically followed the installation guide, but did need to do some minor changes to the eB Datalayer to connect this to the latest version of eB.

However, I then needed to upgrade the Bentley iringtest.bentley.com only to find that while the majority of the functionality was working certain parts were not.

This seemed to be related to the server and the configuration of IIS 7.0

With the assistance of the iRing Tools Community we established what it was not, but we had to try a lot of “solutions” via google, before finally we determined that SP2 and security were the main cause of the issue.

Now having stood up the iRing Tools Server quite a few times, and used them on a few different projects, it was frustrating that one server installed and was up and running by simply following the installation procedure and yet the server that had been up and running could not be upgraded.

However, it was only that a minor frustration, within 24 hours the community had delivered enough to ensure we were up and running.  The server is not a simple application where you can click install and let it run.  This is a server which will be servicing a projects or enterprises needs and as such there should be an expectation that this will need configuration to suit a user’s server environment.

What was also interesting was that the step to ensure the Apache Services are running, are actually not needed, so you do not need to expose the Apache Services for a successful implementation.

There are still some missing items, the Reference Data Editor which was great to walk new users through the Reference Data Library, is missing and I suppose I should plug in the dot15926 Editor to see if this has the same functionality.

For now, the thought of a new user adding items to their RDL and adding classifications, using the spreadsheet, will not work, and I cannot introduce new users to the RDL using that technique.

I ask the question of the iRing community … what are you using to view and browse your RDL today?

I will be following this blog up with how I managed to edit the RDL, but for now, try the install on a clean Windows 2008 R2 server, and you should have no issues.  If you do, then ensure they are logged so we can all learn and move forward with our iRing projects.

The post iRing Tools Server Installation appeared first on iRINGToday.