The Holy Grail in information exchange is that our machines know what our data means so that they can move it between business partners reliably without needing us to guide them. ISO 15926 has come a long way towards that goal by pushing the meaning of the data into the data itself instead of using AI software. But as short a time as five or six years ago few people in the capital projects industry had heard of it. To some, it may seem that the standard is a fad, sprung suddenly out of nowhere. But in reality ISO 15926 builds on several decades of work in the field of information exchange, and various parts of the standard have been tested and used in the heat of battle on a number of large, world-class projects.
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!
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.