Sean Barker

Sean Barker

Last updated on 24 October 2019

Sean Barker is an Information Management Specialist 

I have an embarrassing admission to make. For years, part of me worked on the LOTAR project (1) developing preservation standards for Product Data Management (PDM), while another part was making those standards obsolete by creating an Integrated Design Environment. And I didn't connect the two parts together.

The first thing I should do is not explain PDM - it's too complex for a short blog and people shouldn't worry about it unless their project gets bigger than a team-of-teams (about eighty people). Think of PDM as provenance on steroids, where even a simple sign-off is backed up by a ten-volume procedures manual and where the people who sign the approvals must be approved to do so by an approved organization.

My last book (2) gave more detail on PDM, but had only two pages on long term preservation. To correct that omission, I've just written another - working title "How can I archive an Aircraft?" The first half briefly covers Aerospace Requirements, OAIS, Archiving-as-a-service and the LOTAR project. The second half gets dirty, going into detail on Computer Aided Design (CAD) and PDM. I had expected writing it to be straightforward, but the chapters on PDM went pear shaped, and I have been trying to work out why.

In PDM, a work order is needed to authorise any change to the design master and the work order and all the sign-offs are PDM data. Pre 1990s, processes were based on "drawing-as-master" (figure 1a), where one drawing controlled several parts. The LOTAR standards are based on "CAD-model-as-master" processes (Figure 1b) that were the mainstream in the 2000s when LOTAR mapped out its approach. At the time, CAD was one of the few detailed modelling systems, so CAD became the de facto master for the whole design (drawings were relegated to an output from the CAD model). Other disciplines had modelling software, but used only to support the designers' calculations.

Barker 1

But in the background, engineers like me were quietly developing methods of sucking data out of one chunk of software so it could be used directly by the next step in the process chain. At the time, this was thought of as creating bridges between "islands of automation". Move on decade or so, and these "archipelagos of automation" were now denigrated as "stove-pipe solutions" which prevent cross-links between processes. The future would be an Integrated Design Environment (IDE).

An IDE supports multiple models of a part, grouped together into views (Figure 1c). For example, there could be a physical design view (e.g. CAD, stress model, electrical paths model, and so on), a manufacturing view, a support view, etc. Developments in any one view would be notified to users of the other views, so the whole design could be kept up-to-date. In an IDE, a work order will give permission to change one or more views - for example, if, ten years after a part has been designed, a new manufacturing process is developed, then the models in the manufacturing view need updating, but not those in the design or support views.

The ISO 10303 standards lie at the core of model-as-master, and they already contain the view entity (technically a Product_definition). In the CAD-model-as-master process, the view had been just an extra entity between a part and a model that took a default value. But if you change your process then you must change the model for the data generated by the process, and your preservation standards are built on that data model. The good news for my chums at LOTAR is that all the work they have done so far is essentially valid. The bad news is that, because the processes are changing, the original preservation standards need extending.

For everyone else, I assume if you are reading this that you've got off the beach and at least started paddling in the archiving shallows, where provenance is just a couple of metadata attributes. But management will be urging you to go further out to sea - "This document management system will save time and provide more metadata", then, "A workflow engine will make our processes more efficient". And under the water, the provenance models start subtly altering, and before you know it your feet no longer touch the bottom, and you start to worry "Is it deep enough for sharks?"



2) Aircraft as a System-of-systems: A Business Process Approach. SAE International

Scroll to top