Version 62 (modified by gordonrachar, 14 years ago)

--

History of ISO 15926

Status of this document: Working Draft

This document is open for feedback, please post questions and comments in the forum at the bottom of this page. You will need a login to post in the forum.


Contents

    1. Metaphor: Interoperability is Like Heavier-Than-Air Flight
  1. How we Store and Exchange of Textual Information
    1. Dealing with Proprietary Hardware
    2. Dealing with Proprietary Software - Personal Scale
    3. Dealing with Proprietary Software - Industrial Scale
    4. Markup Languages
  2. How we Know and Understand Things
    1. Ontology
    2. The Semantic Web
  3. How we Store and Exchange Plant Information
    1. Plant Information Interoperability Projects
    2. The Initial Graphics Exchange Specification (IGES)
    3. Standard for the Exchange of Product Data (STEP)
    4. PlantSTEP
    5. PISTEP
    6. PIBASE
    7. EPISTLE
    8. Petrotechnical Open Software Corporation (POSC)
    9. POSC Caesar Association
    10. FIATECH
    11. ISO 15926
  4. JUNK
    1. 1991 - ProcessBASE

Metaphor: Interoperability is Like Heavier-Than-Air Flight

If you are new to ISO 15926 you might think that the question of storing and retrieving digital plant information so that it can be used for more than the initial purpose is a rather new question. It isn't. Interoperability of plant information between different computer systems is more like the development of heavier than air flight (although compressed into a much shorter time.) Interoperability became an issue almost as soon as computers made their way into engineering offices. Many organizations from around the world have been working on this topic for many years, from Owner/Operators, Constructors, Consulting Engineers, and Software Developers. Many standards organizations world wide are involved, some having been created just for this purpose.

There have been many attempts at interoperability, some fizzling out in a few years, some lasting until today. Different organizations, with different needs have tried slightly different approaches. All of these attempts have had to deal with how to convey the meaning of the data as it (the data) is being transmitted. Some solutions are based on limiting the scope of the data in order to simplify the task of conveying meaning, others attempt to allow unlimited scope.

At the lowest level, interoperability is extremely complex, just as the mechanics of flying is extremely complex. Fortunately, when it is mature, using ISO 15926 it will be about as complicated as using flight is today. For instance, your humble author, sitting in the mid-latitudes of Canada in the winter of 2008/2009, is right now thinking about being someplace much warmer for a couple of weeks. Getting there will involve using heavier-than-air flight, but I will not have to concern myself with things like power-to-weight ratios, or the exact curve of the wing to maximize the difference in air pressure between the upper and lower surfaces. All I will have to do is watch my daily newspaper for tropical vacations and phone my travel agent. Similarly, when ISO 15926 is mature, all a typical user will need to know is what button to push to connect to a business partner.

ISO 15926 is a solution to interoperability of plant information made possible by the confluence of four areas of interest:

  • How we store and exchange textual information
  • How we know and understand things
  • How we use the Internet to find things
  • How we store and exchange plant information

We may well end up with different tools for interoperability, just as there are many solutions today for heavier-than-air flight depending on one's need (glider, propeller airplane, jet airplane, helicopter, lifting body). But just as in flight, where the common element to all modes of flight is a particular shape of whatever is doing the lifting (wing, rotor, aircraft body), we are starting to see that the dictionary of terms is becoming a common element. In Figure 1, below, this is shown as the data dictionary, ISO 15926 part 4.

Error: Macro Image(History01.JPG, 500px) failed
Attachment 'wiki:ISO15926Primer_History: History01.JPG' does not exist.

Fig 1 - History of ISO 15926


How we Store and Exchange of Textual Information

Human society has always had to find ways to manage, store, and retrieve information. The Library of Alexandria, which burned down in 48 BC (according to one story), is an example of both the best technology for managing information in hard-copy form, and a major limitation of doing so.

With the advent of computer-managed storage in the mid twentieth century, information managers have had to grapple with two problems:

  • Survival of information beyond the lifetime of proprietary hardware and software.
  • Moving a large amount of information between proprietary systems.

Dealing with Proprietary Hardware

A typical example of these types of questions is a help desk enquiry from the mid 1980's:

I have data I want to keep for decades. Should I invest in a good card reader, or should I transfer my data to these far more efficient but newfangled "floppy disks"?

Unfortunately, the best answer to this kind of question has always been rather labor intensive. That is, the only reliable way to keep digital information for decades is to upgrade your storage media every few years to whatever is the latest and greatest at the time. For personal use, in the 1980s it would have been 5 1/2" floppy disks. By the 1990s you would have had to copy all of your archive to 3 1/2" floppies. Then, sometime around 2000, the best storage medium became CDs, and a bit later, DVDs. At first everyone thought they would last for decades, but sometimes they didn't even last two years:

Restored DVD key to conviction in criminal case

Now, nearing the end of the first decade in the twenty-first century, flash drives are looking like they will be readable for quite awhile. But ask yourself the likelyhood of personal computers having USB ports in twenty years? Maybe, but whether in twenty years or forty years, at some point you will still have to load up your thumb drives and copy them to some new media; perhaps a three-dimensional, holographic memory block.

Dealing with Proprietary Software - Personal Scale

Unfortunately, even if you go through the exercise of transferring your archive every few years, how are you going to open the files twenty-five years from now? In the lifetime of your humble author (who is so old he can remember when an entire family had to make do with a single telephone), the word processor of choice has gone from WordStar, to Word Perfect, to Microsoft Word. (There has to be a good Mac vs PC joke, but I can't think of any right now!)

Working with Word 2002, now, as this is being written, we can see that Word users can open the following word processor file formats:

  • Word 2.0
  • Word 5.1 for Mac
  • Word 6.0 (95)
  • Word Perfect 5.0
  • Works 2000

Where is my beloved WordStar? In addition to copies of all my data files, do I have to keep copies of all my old authoring software? And even if I do, what will I run it on? Do I also have to keep a working model of each vintage of personal computer? What if it breaks down?

So now, if I actually want to be able to retrieve my personal archives for decades (perhaps I am thinking that after I become a famous author, a publisher will give me a million dollar advance to write my memoirs), I will have to open each of my archived files every couple years and somehow transfer the contents to whatever the new authoring software is.

This will remove the problem of having to keep old hardware and software around, but will introduce a new set of problems:

First, this solution will create an upper limit on how much information I can keep around. Since it will take a certain amount of time to upgrade my archive each cycle, I will have less and less time each round to create new information. Eventually I will just finish one upgrade when I will have to start over with new technology.

Second, who's to say there will always be a clear and easy upgrade path from one authoring software to the next? For example, what if I had a large number of files authored with obscure CAD software? What if the dominant players did not write the appropriate conversions into their offerings?

Well, there is another option:

Error: Macro Image(History_LongtermStorage.JPG, 500px) failed
Attachment 'wiki:ISO15926Primer_History: History_LongtermStorage.JPG' does not exist.

Fig 2 - Long Term Information Storage Using the Internet

(This is taken from a Slashdot discussion on the topic of long-term data storage. Here is the complete article.)

[GPR: remove LongtermStorage.jpg ]

Dealing with Proprietary Software - Industrial Scale

If the problem of moving information between proprietary systems is daunting on a personal level, try to imagine what it is like for organizations that create large bodies of documentation. For instance, every model of aircraft you see today requires several million pages of documentation which has to be revised and published every quarter. (XML Handbook) The combined documentation libraries of the aircraft industry probably rivals the size of the entire world wide web. Yet every few years the dominant hardware changes, and along with it, the software used.

Governments and law firms are in a similar situation.

Markup Languages

It is precisely these issues, the survival of information beyond the lifetime of proprietary hardware, and moving a large amount of information between proprietary systems, that prompted Charles Goldfarb, with Ed Mosher, and Ray Lorie at IBM to create "Generalized Markup Language" (GML) in the early 1960s.

  • GML
  • SGML
  • HTML
  • XML

Except for GML (which became SGML), all of these markup languages are in wide use today. SGML is used for managing large bodies of textual information. HTML is the language of the World Wide Web, linking documents for human retrieval. XML is increasingly being used to manage large bodies of knowledge, including plant information with ISO 15926.

For more information:


How we Know and Understand Things

When we go beyond custom-built methods to exchange information between two particular computer applications; when we try to design a way for any two computer applications to connect to each other automatically without having to know anything at all about each other; we confront the question of how we represent knowledge. This is not just sophistry; if two computer systems are to connect to each other automatically, we must have a way to embed the necessary context (the understanding that humans bring) within the data that is being exchanged. For this we need to understand how we know things. The study of how we know things in philosophy and mathematics is ontololgy.

Philosophy, sufficiently advanced, is indistinguishable from bulls**t. --Greg Berge

Ontology

The study of ontology is well beyond what anyone will need to know in order to use ISO 15926, and therefore beyond the scope of this primer. However, a brief example to explain what ontology is will be helpful:

Your humble author rides a bicycle to work most days. (Among other things, it lets me indulge in the luxury of eating the fine Ukrainian food my wife cooks for me.) The distance to work makes a nice workout but is beyond walking if the bicycle were to break down. Therefore, I have developed what you might call an Ontology of Things That Will Carry A Bicycle.

Now, in Western Canada, which to most Europeans is but a few years out of the horse age, the pickup truck is king. In Western Canada, Real Men all have pickups. As you can see from Figure 3, there is ample room in a pickup truck to carry a bicycle.

Error: Macro Image(History_PickupTruck.JPG, 150px) failed
Attachment 'wiki:ISO15926Primer_History: History_PickupTruck.JPG' does not exist.

Fig 3 - Pickup Truck

So it is not hard to imagine that if my bicycle broke down on the way to work, I would try to think of everyone who owned a pickup truck that might have driven it to work that day. Suppose one such friend is Bill, who owes me a big favor. But when I talk to Bill he tells me he can't help me. He tells me he is going camping that weekend and to get a fast getaway he's already loaded his camper. How do I know this will be a problem? Because I know that when you load a "camper" onto a pickup truck, there is no room for a bicycle.

Error: Macro Image(History_Camper.JPG, 150px) failed
Attachment 'wiki:ISO15926Primer_History: History_Camper.JPG' does not exist.

Fig 4 - Pickup Truck with a Camper Loaded

But hold on! My father used to own a camper for his own pickup truck (he being a Real Man and all), and I remember looking inside it. There was space just inside the door that might be able to fit a bicycle. Alas, Bill tells me, he has already filled the available space with his other camping gear leaving no room.

So with that conversation, I start planning how to get home on public transit. Being a Real Man myself, I own a pickup truck and will have to drive it back to work to pick up my bicycle. But by coincidence, a new engineer, who's just emigrated from the Czech Republic, walks by and overhears my dilemma. He tells me that when he moved to Canada, he brought with him his Felicia Fun. I can't imagine what that is, but judging by the expectant smile on his face I suspect it might be relevant so I ask what a Felicia Fun is. Being new to Canada he doesn't know how to describe it so he says it is like the F150 his friend has, but a bit smaller. I immediately accept his kind offer to drive me and my bicycle home after work. (Oh, and I owe him a really big favor. Perhaps I will invite him in for Ukrainian food!)

How did I know that a Felicia Fun would carry my bicycle? Because it is "like an F150", which is the name of a particular brand of pickup truck. Figure 5 shows the relationship of things in my ontology.

Error: Macro Image(History05.JPG, 400px) failed
Attachment 'wiki:ISO15926Primer_History: History05.JPG' does not exist.

Fig 5 - Ontology of Things That Will Carry A Bicycle

This example is all most people will ever have to know about ontology. But if you are interested in digging deeper, the W3C Consortium has created two languages with which to create ontologies, Resource Description Framework (RDF), and the Web Ontology Language (OWL). Neither are for the feint of heart.

The Semantic Web

The Semantic Web is another topic that most people will not have to know about in order to use ISO 15926. However, it is interesting as background information.

When Tim Berners-Lee invented the World Wide Web in 1990, he envisioned much more than what we see today, essentially, version 1.0. He envisioned an web environment where people could ask their personal digital assistants questions like "Is there a medical doctor near here that specializes in geriatrics who has an open appointment before Friday noon?" and then go for coffee.

Currently the World Wide Web is built to link documents primarily for human consumption. Computers can process web pages for layout and visual format, but they have no way to process the semantics; to know what they mean. Thus, if you wanted to find a doctor in the example above, you may be able to use the World Wide Web to get a list of doctors and their specialty, and maps with which to judge the distance, but you would still have to call each doctor's office individually to see if she is taking new patients, and if there is a suitable open appointment. Using existing sources of information, one might get lucky and get an appointment with the first call from the Yellow Pages, but it could easily take much longer.

The Semantic Web is all about describing things in a manner that computers can understand, so that you can ask questions like this one and let a digital assistant do the leg work. Using Semantic Web technology, data can be shared and re-used across application, enterprise, and community boundaries.

ISO 15926 uses some Semantic Web technology to describe plant objects in a way that computers can understand. Where it differs from the Semantic Web is in the level of precision. The Semantic Web initiative seeks to map all the legacy data on the World Wide Web in all its chaotic glory to give "pretty good" information. In the field of Plant Design, "pretty good" is a pretty good way to blow things up and kill people. ISO 15926 requires more precise definitions, but uses some of the same tools.

If you are interesting in knowing more about the Semantic Web, here are some references:


How we Store and Exchange Plant Information

Interoperability of plant information between proprietary systems became an issue almost from the advent of CAD in the 1950s. There are many organizations dedicated to interoperability in just about every industy. Interoperability in the plant industry started in the mid twentieth century U.S. defense department, and expanded to include areospace, automotive, and plant. Included here are some of the more significant initiatives.

Plant Information Interoperability Projects

  • IGES
  • STEP
    • PlantSTEP
    • PISTEP
    • PIBASE
  • EPISTLE
  • POSC Caesar Association
  • FIATECH
  • ISO 15926
  • ProcessBASE (???)

Error: Macro Image(History_STEP.JPG, 600px) failed
Attachment 'wiki:ISO15926Primer_History: History_STEP.JPG' does not exist.

Fig 6 - History of STEP

The Initial Graphics Exchange Specification (IGES)

Computer based graphics systems started appearing in the mid 1950s in the U.S. Defense industry. By the 1970s the Department of Defense wanted a neutral format that would allow the digital exchange of information between CAD systems. The IGES project was started in 1979 by a group of CAD users and vendors, with the support of the National Bureau of Standards, now know as NIST. In 1980 the NBS published what they called the Digital Representation for Communication of Product . This standard was also published by ASME/ANSI as Y14.26M, which is how many military standards refer to it.

By 1998, any computer aided software vendor who wanted to sell to the DoD had to support reading and writing IGES format files. IGES has been in the automotive, shipbuilding and defense industries for small parts up to entire aircraft carriers where the digital drawings have to be used many years after the vendor of the original design software has gone out of business.

By 1994 a competing standard, STEP, was released as an ISO standard. Development of IGES was stopped.

Standard for the Exchange of Product Data (STEP)

The development of STEP started in 1984. The objective was to provide a means of describing product data throughout its lifecycle, independent of any particular computer system.

STEP shares many goals with ISO 15926. STEP's neutral files mean that product data can archived over many years, and can be shared between different software systems. As well, the standard is implemented within commercial software particular to the engineering discipline, and so will be invisible to the average user.

Where STEP differes is in the manner in which templates and descriptions of plant objects are changed. STEP requires a lengthy review before approval of changes, whereas ISO 15926 allows class extensions to be made in as little as five mintues, by trained and approved individuals.

In 1994 STEP was issued as ISO 10303 Industrial systems and integration - Product data representation and exchange.

STEP's credits include:

  • 1995 - Boeing 777
  • 2000 - GM
  • 2004 - Endorsed for U.S. Navy

References

STEP

PlantSTEP

PISTEP

PIBASE

EPISTLE

European Process Industries STEP Technical Liaison Executive

EPISTLE is a virtual organization with no employees, no funding, and no legal status.

The membership of EPISTLE is open to those organizations that are consortia of companies working to develop standards for information management and prepared to commit resources with other members to achieve commonly agreed objectives.

Individual companies and other organizations may attend EPISTLE meetings on an observer basis, but are encouraged to join or form a consortium that is a full member of EPISTLE. Observers may only speak on invitation of the chair of the meeting concerned, and may be asked to leave the meeting at the discretion of the chair.

Membership The founding members under this new constitution are:

  • PISTEP
  • POSC/Caesar
  • USPI-NL

References

Petrotechnical Open Software Corporation (POSC)

POSC started life as a consortium of 100 companies engaged in the production, refinement, and distribution of petrochemical products and of companies that supply hardware for those operations. POSC worked to share information among its members and to promote useful software modeling, data, and application integration standards.

At the 2006 Standards Summit & Reception in Houston on November 8, 2006, POSC Rebranded itself as Energistics

From its new website http://www.energistics.org/:

Energistics' rebranding supports the new leadership goal of executing a market-focused business strategy. The mission of Energistics is to deliver to the upstream oil and gas industry the means to produce, deploy and maintain common information and data standards.

So it looks like only the name has changed.

POSC Caesar Association

http://www.posccaesar.org

  • Caesar Offshore Project
  • PetroChemical Open Software Corporation

The Caesar Offshore Program started in 1993 as an industry driven research and development project under the name of Caesar Offshore Program. It was sponsored by The Norwegian Research Council, Aker, DNV, Kværner, Norsk Hydro, Saga Petroleum and Statoil. The purpose of the project was to benefit the oil and gas industry by developing a product model for life cycle information. The focus was on standardizing the technical data definitions for facilities and equipment associated with onshore and offshore oil and gas production facilities. In the period 1994-96 Caesar Offshore Program was defined as a project of Petrotechnical Open Software Corporation (POSC), Houston, and changed its name to the POSC Caesar Project.

The technical work of POSC Caesar was more and more related to the ISO STEP standard and influenced by similar work in European standardization organization such as PISTEP in UK and USPI in the Netherlands through the virtual organization EPISTLE.

POSC Caesar Association was founded in 1997, as a global, non-profit, member organization that shall promote the development of openly available specifications to be used as standards for enabling the integration and interoperability of data, software and related matters for e-engineering and e-commerce.

POSC Caesar has a special responsibility for the maintenance and enhancement of ISO 15926 “Integration of life-cycle data for process plants including oil and gas production facilities". However, the organization shall be flexible and at all times align its activities with the needs of its membership.

POSC Caesar works now as a global standardization organization in close collaboration with other standardization organizations in Europe, USA and Japan.

FIATECH

something

ISO 15926

ISO 15926 is a standard for data integration, sharing, exchange, and hand-over between computer systems.

In the early 2000s, for modeling-technical reasons POSC/Caesar proposed another standard than ISO 10303, called ISO 15926. EPISTLE (and ISO) supported that proposal, and continued the modeling work, thereby writing Part 2 of ISO 15926. This Part 2 has official ISO IS (International Standard) status since 2003.

References

JUNK

1991 - ProcessBASE

Note to me: looks like a program to simulate processes (plant, computer?). it spawned some thought about transferring information. which lead to ProcessBASE, which lead to ISO 10302-AP221, which lead to STEP (or it already existed?) which lead to 15926

References


During 2008 the interest and commitment to ISO 15926 as the preferred way to interoperate information between companies has been significantly accelerated. Along with all of the progress made by several acceleration projects, a watershed moment occurred during the ISO 15926 Software Vendor Workshop last May 2008 that signaled the “passing of the baton” of leadership to the software vendor community.

But it's taken awhile.

In the early 1990's quite a few organizations started projects to explore the possibility of developing a common language describing plant objects. Over the next decade many of these organizations found out about each other and decided to pool their resources. But the tools that ISO 15926 is being developed with have their roots as far back as the 1970's.


Discussion

You have no rights to see this discussion.

Home
About PCA
Reference Data Services
Projects
Workgroups