A Web-enabled virtual repository for supporting distributed automotive

component development

Dave Browna, David Leala, Chris McMahonb,*, Rose Crosslandc, Janardan Devlukiad

aCEDAR Ltd, London, UKbDepartment of Mechanical Engineering, University of Bath, Claverton Down, BA2 7AY Bath, UK

cAdiuri Systems Ltd, Bristol, UKdLand Rover, Gaydon, Warwick, UK

Received 20 October 2004; revised 21 December 2004; accepted 22 December 2004

Abstract

This paper describes a web-enabled repository system that has been designed for supporting distributed automotive component

development. The repository is based on an integrated product and process life-cycle information model, derived from ISO standards and

using EPISTLE generic entity modelling principles. This core model can be used with reference data libraries, such as for activities,

components, documents and properties. The scope and characteristics of the model are described, along with its relation to standard product

data models and classification schemes. Component design and analysis representational models are referenced as resources through

document meta-data, with virtual access via the repository. The modelling approach is compatible with the current development of

ontologies and topic maps for the Semantic Web, with an inter-operability route via the Resource Description Framework (RDF). The paper

also provides an outline of the system architecture, the associated Web tools and the Business Object library for building client-server

applications. An industrial application for fatigue studies is described, illustrating comparison of analysis and test data, repository search and

provision of best practice advice. The aim is to produce a flexible system that can be populated and extended directly by engineers, shielding

them from the details of the information model.

q 2005 Elsevier Ltd. All rights reserved.

Keywords: Product and process modelling; Generic entity core models; Engineering repository; Semantic Web; Fatigue analysis; Classification standards

1. Introduction

In automotive engineering, as in other manufacturing

industries, there is a trend towards Virtual Prototyping (VP)

in order to reduce dependency on more costly and time-

consuming physical testing. There has also been a growth in

concurrent engineering and distributed design and analysis,

in order to maintain international competitiveness. These

trends increase the need for sharing and integrating

information and knowledge between team members. An

important aspect of this sharing and integration is the

capture of key information and knowledge about

1474-0346/$ - see front matter q 2005 Elsevier Ltd. All rights reserved.

doi:10.1016/j.aei.2004.12.001

* Corresponding author. Tel.: C44 1225 384026; fax: C44 1225 386928.

E-mail address: enscam@bath.ac.uk (C. McMahon).

the Component Development Process (CDP), both for

audit purposes and for future reference, since in many cases

component designs are derived from previous designs.

The engineering data warehouse described in this paper

is intended to assist in capturing a record of the activities

conducted during the CDP. The aim is to record the process

information in a consistent manner so that it can be easily be

accessed across a distributed network and efficiently

retrieved for subsequent re-use. The repository is based on

a life-cycle information model developed using generic

entity modelling principles as part of a European collabora-

tive research project named INTEREST [1]. This project

aimed at providing support for structural integrity assess-

ment of mechanical components, with a focus on durability

analysis. The assessment procedure included a range of

Advanced Engineering Informatics 18 (2004) 173–190

www.elsevier.com/locate/aei

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190174

design, analysis and test activities. The life-cycle integration

is aimed at the co-ordination of such activities and sharing

of component characteristic data. Detailed geometric

representations are referenced via document meta-data, so

the data warehouse is referred to as a Virtual Repository

(VR).

The VR is intended to serve as an information base for

both general-purpose client applications, as well as more

specific applications requiring different views of the

repository contents. Ubiquitous access to Internet/Intranet

technology means that it has become the natural delivery

mechanism for exchanging and sharing information and

thus the VR has been implemented using Java technology.

In the INTEREST project two other general purpose Web

applications have been developed using the VR server. A

Job Description System (JDS) [2], coupled to a Workflow

Manager, captures process information, including a record

of design decisions and rationale, and an adaptive

hypermedia system named the Best Practice Advisor

(BPA) [3] provides engineers with detailed guidance on

how to carry out process tasks according to the working

context. These Web-Enabled developments formed part of a

larger programme of work in INTEREST. The full system

included a Tool Manager [4], which combines tool

wrapping and tool building capabilities with parametric

studies, multi-disciplinary optimisation, Monte–Carlo simu-

lation and design of experiments; a Fatigue Toolbox which

was used for an associated evaluation of fatigue analysis

packages [5]; and reliability analysis modules for determin-

ing fatigue lifetime probability distributions for metal

components subjected to constant amplitude, random or

deterministic cyclic loading [6]. Refs. [2–6] describe the

overall collaborative design analysis environment, the full

system architecture and the structural integrity assessment

aspects of the work.

This paper focuses on the VR, with some coverage of its

coupling to the JDS and BPA clients. Section 2 describes the

background to generic entity modelling and related product

data modelling and Semantic Web1 [7] developments.

Section 3 presents an overview of the scope and character-

istics of the INTEREST Information Model (IIM), an object

model with graph data structures and a semantic net of

associations on which the VR is based. Section 4 provides

an overview of the Business Object API library, a Web-

based Data Management support tool and the links with the

BPA and JDS. This is followed in Section 5 by some

examples of how the Data Manager can be used to browse

and search the repository. The development approach is

appraised in Section 6 based on the experience of an initial

prototype, the industrial application and prospective devel-

opments are outlined in Section 7, and finally we conclude

by summarising our development work, the initial results of

the research and possible wider applications.

1 http://www.semanticweb.org/

2. Modelling background

A number of approaches to the modelling of database

schema have been developed, including Entity-Relationship

(E-R) modelling [8,9] and object-oriented approaches and

the associated development of modelling and analysis

techniques such as UML and the Model View Controller

(MVC) principle. From the late 1980s and throughout the

1990s, Wand and Weber conducted a research program on

the use of ontologies to aid conceptual modelling, e.g. [10].

More recently, Sugumaran and Storey [11] have presented a

methodology for creating and managing domain ontologies,

including both basic and domain dependent constraints for

use with database designs. The On-to-Knowledge project

[12] has developed a similar methodology for ontology

creation and management, supported by a set of tools

compatible with the latest developments for the Semantic

Web. Another research tool which assists domain ontology

building from Web documents is OntoLearn [13]. This

combines Natural Language Processing (NLP) for filtering

domain specific terms with semantic interpretation using

semantic nets.

An alternative or complementary development approach

is to make use of standardised models or model patterns. In

commercial applications there were, until comparatively

recently, few publications of industrial generic data models,

e.g. [14] with a focus on manufacturing and [15,16] for

business applications. As developers of such enterprise

models have noted, in mainstream commercial applications

many data modelling efforts have been previously created in

other organisations, or at least something similar. Further,

there is often considerable overlap between the contents of

different databases with each providing views for specific

applications. Such data redundancy can be reduced if an

enterprise-wide perspective is taken to integrate different

systems more effectively through the use of Generic

Enterprise Models (GEMs)—object libraries defining

classes that are generic across an enterprise. As well as

helping to integrate existing legacy systems, GEMs can also

facilitate new developments, especially if generic reasoning

is added to the core classes. The development of Business

Objects for different industrial domains by the Object

Management Group (OMG) is a current example. Projects

such as ArchiMate2 are aiming to facilitate integration of

enterprise systems using meta-modelling and visualisation

tools. Modern commercial PDM, ERP, MRP, SCM and

CRM applications are also evolving into more integrated

Product Lifecycle Management systems, increasingly with

an e-Business orientation.

In the engineering field, efforts at creating standardised

data models have centred on the STandard for the Exchange

of Product model data (STEP) [17]—ISO 10303. STEP

supports a wide range of engineering disciplines with

2 http://archimate.telin.nl

Fig. 1. Outline of class hierarchy in the INTEREST information model.

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190 175

different Application Protocols (APs) being developed by

experts in different fields, e.g. AP 209 for Finite Element

technology and AP 214 for Automotive Mechanical Design

Processes. As part of the OMG ManTIS effort, a set of PDM

enablers3 has been produced for providing a standard

object-based interface to typical PDM/PLM capabilities,

such as product structure and document management.

2.1. Generic entity modelling and ontologies

The generic entity modelling approach can be regarded as

a hybrid approach between the application of a modelling

methodology and the re-use of model templates, in that a

small number of modelling principles are applied to a high-

level model framework. This approach has its origins in the

General AEC Reference Model [18] which laid out a number

of product data structuring principles. The approach was

adopted and extended by the European Process Industries

STEP Technical Liaison Executive (EPISTLE), a consor-

tium of companies for the development of conceptual models

for process plants. The EPISTLE methodology has since

been used in STEP in the development of AP 221 for process

plant; the Engineering Analysis Core Model (EA C-ARM),

an Application Resource, part 107; in model developments

undertaken by the POSC4 consortium for the oil and gas

industries; and in the ElectroNet project [19] for power

systems engineering. The International Alliance for Inter-

operability have also used a core model in developing the

Industry Foundation Class library (IFC)5 for the construction

and building industries. The aim of these core models is to

support life-cycle integration across a range of engineering

activities. Different views of the data can be extracted from

the core models, as required for specific applications. This

approach is thus in keeping with the original ANSI-Sparc

architecture [20].

More recently, the Design Repository Project [21] at

NIST6 is aiming to provide a technical foundation for

repositories supporting design knowledge, with particular

focus on the concept stage. This project also involves the

development of an OO generic informational model,

taxonomies of terms and a Web-based repository. The

object model has a number of features in common with part

of the IIM, with the physical_object schema being the main

area of overlap. Another meta-modelling framework

integrating different aspects (views) is the Knowledge

Intensive Engineering Framework (KIEF). This serves as an

intelligent CAD design system using a pluggable meta-

model mechanism to link to different design and analysis

tools [22].

One feature of EPISTLE based modelling is that the

generic entities form part of a class hierarchy defining

3 http://www.omg.org/homepages/mfg/mfgadopted.htm4 http://www.posccaesar.org/5 http://cic.vtt.fi/niai/technical/IFC_2x/index.htm6 http://www.nist.gov/msid/pe.htm

the model context, as shown for the principal entities in the

IIM in Fig. 1. As the scope of the IIM is quite broad, the

model framework has some similarity with high level

ontologies, such as the Suggested Upper Merged Ontology

[23] being developed by IEEE. This incorporates elements

from other standardisation efforts such as the Process

Specification Language (PSL)7. The correspondence

7 http://ats.nist.gov/psl/

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190176

between semantically rich data models and ontologies has

long been noted as, for example, discussed in the Kactus

project [24] which produced a library system supporting

ontologies defined in both knowledge representation

languages (Ontolingua and CML) and the STEP data

definition language, Express. Welty and Guarino [25] also

note the virtual synonymous industrial use of ‘conceptual

model’ with ‘ontology’.

In the literature the term ‘ontology’ is used to refer to a

wide range of shared conceptualisations from simple

catalogs and glossaries through to knowledge rich models

including sophisticated logical relationships and con-

straints. This has given rise to the notion of an ontology

spectrum based on the degree of complexity, as described

by McGuinness [26]. The IIM lies towards the upper

middle part of this spectrum with similar characteristics to

frames, but currently with only basic inference capabilities

in the VR, mostly related to inheritance.

The IIM generic entities are implemented as classes

with instances which are themselves classes. With this

structure the model can be populated with classes which

can either be user-defined, or imported from standard

Reference Data Libraries, as discussed in Section 3.5. In

this respect the VR provides an extensible structure

similar to ontology development tools such as the Protege

2000 frame-based, metaclass system [27], OntoBuilder/

OntoEdit [12] and Hozo [28] for device and process plant

ontologies.

The terminology adopted here should not be confused

with that used in the Knowledge Representation field, as

should be clear from the context. For example, property is

used in both its normal engineering sense, as well as to

refer to associations/predicates such as in Resource

Description Framework Schema (RDFS); individuals

refer to objects that are instances of a class with a real-

world existence; and roles refer to associations of things

involved in activities. The term entity is used synony-

mously with entity type in information modelling.

3. Information model description

The IIM has a modular structure containing the following

related schemas:

†

A high level framework for distinguishing between

classes of things, individual things and the

relationships between things, which can be applied to

objects in the other schemas. The main relationships are

class_specialisation (is-a) for sub-typing;

class_membership for classification of

individuals; thing_set for collections of things;

class_of_association and association for

other relationships between classes and between indi-

viduals; and derivation and version_succes-sion for version management.

†

Physical object schema for classes of physical objects

and their composition, connection and possession

relationships. ‘Physical object’ is used in a very general

sense, including:

– function, such as rotating parts (e.g. shafts) and

powertrain parts (e.g. pistons);

– form, for the overall object shape or configuration,

such as for thin shell parts;

– features, such as holes, ribs and threads;

– component and feature specifications for designed

parts;

– material type, fabrication and surface finish types; and

– machines, assemblies of components which perform

useful work, such as engines, machine tools and

computers.

†

Activity schema defining both activities conducted by

parties (persons and organisations) and physical pro-

cesses. The schema differentiates between general types

of activity (e.g. FE analysis) and individual activities

(e.g. a specific analysis that is carried out), each with

their own set of associations, such as for sequence,

composition and roles. The generic activity type covers

processes, tasks, sub-tasks etc.

†

Document schema describing the content, form, location,

version and other document meta-data. A number of

associations between different documents are also

defined, including references, derivations and copies.

This schema includes separate document content objects

which can be linked to corresponding documents.

†

Property schema describing the properties possessed by

things, in particular physical objects, activities and states.

Properties are differentiated by their value-type

(numeric, string etc.) and classified primarily according

to their physical type (e.g. mass). The schema can also be

used to record the way in which properties can be related,

such as represented in the form of graphs or surfaces

through definition of property functions (e.g. for storing

fatigue curves).

†

State schema for recording the states of a physical object,

defined by the values of its set of properties at a given

time. The properties of different states are recorded as

associations, with further associations to the activities

causing transitions between states.

†

Administrative schema containing classifications for

personnel and organisations (collectively referred to as

parties), basic location information for parties and

machines, ownership of objects and relationships

between parties, such as commercial transactions.

Although the INTEREST project has focussed on fatigue

studies, because of its generic structure the model should be

applicable to design-analysis processes in general. The

position of some classes in the hierarchy reflects the

business perspective; e.g. document and person are in

separate high-level branches rather than being sub-classes

of physical_object.

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190 177

3.1. General features of the model

3.1.1. Use of the EPISTLE principles

The IIM development has been influenced by the

following EPISTLE modelling principles:

1.

Entities should represent the underlying nature of the

things being modelled, rather than reflecting a specific

viewpoint or role.

2.

They should form part of a class hierarchy of generic

entities defining the context of the model, i.e. the

application domain(s) for which it is valid. The model

scope, which is what it contains, is the same as, or lies

within its context.

3.

Activities and associations should be represented by

entities. An activity is the generic entity for something

happening; this includes processes, tasks and sub-tasks

etc.

4.

Relationships (which in this context refer to the links

between entities on ER diagrams, rather than the more

general sense in UML) should be reserved for the

involvement of entities with activities or with associ-

ations; e.g. a composition_of_activity associ-

ation has a whole and a part relationship with activity.

5.

Candidate attributes should be treated as representing

reified relationships to other entities.

As the IIM closely follows these guidelines, rooted in

Extended ER modelling, this results in an extensively reified

object model through the application of 3–5 above. The

model thus contains relatively few attributes and more

association classes compared to typical object models.

Although designed for a different application scope, the

IIM shares some generic entities with EPISTLE. There are

also some synonymous terms; e.g. physical_object in

Fig. 1 corresponds to material in EPISTLE. In EPISTLE

terminology, the IIM sub-schemas are referred to as subjects

and these can be distinguished by a set of qualifiers for

instantiation, lifecycle and reality. The qualifiers themselves

consist of mutually exclusive concepts; e.g. for the life cycle

qualifier these consist of Actual, Required, Planned and

Predicted, which are disjoint generic entities. The IIM has

not implemented these qualifiers, though some of these

characteristics, as required for the INTEREST CDP, have

Fig. 2. Class specialisatio

been implemented directly as part of a simpler classification

structure.

In the following sub-sections, ‘relationship’ and ‘associ-

association’ are used in their UML sense, with relationships

including associations, dependencies, aggregations and

generalisations.

3.1.2. Classification structure

Rather than using explicit sub-typing for recording the

class hierarchy, the IIM uses data dictionary classification

with the model_classes in Fig. 1 being populated with

instances which are themselves classes; e.g. the dictionary

class steel is an instance of material_structure_-type. The class_specialisation relationship

defines the class hierarchy and can be interrogated bi-

directionally to find the specialisations and generalisations of

a class, both of which are 1:many resulting in a graph

structure (see Fig. 2). The individuals in a given class are

defined via the class_membership relationship. An

individual is defined as something that has a unique

existence with a given lifetime. Hence there can be individual

activities, documents and components etc., the latter

corresponding to actual manufactured items. When a new

individual is created, it is an instance of one of the individual

classes and can be classified through class_member-ship relationship(s) as instance-of class(es) belonging to

the corresponding model_class. For example, there may

be a class_of_activity, ‘Execute Fatigue Analysis’,

in the activity class tree, as say a specialisation of

‘Engineering Analysis’. Actual fatigue analyses that have

been carried out are recorded as instances of activity,

each with a class_membership relation to the ‘Execute

Fatigue Analysis’ class. These analyses may have other

activity classifications, such as for the project in which they

were conducted, so that they can be found through different

drill-down routes in the activity class hierarchy.

Not all the generic model classes have corresponding

individuals, though. For example, classes of materi-al_type, as in Fig. 1, do not instantiate directly into

individuals. Hence different types of aluminium, say, are

instantiated as classes of material_structure_-type, using class_specialisation relationships

as required. Such material types can be related to design

n and membership.

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190178

specifications and hence to individual components, as

described in Section 3.3.

The advantages of using this data dictionary approach are

that:

†

It results in a simpler data model, usually with many

fewer entities compared to models using explicit sub-

typing. In the above example, using explicit sub-typing

each type of activity (e.g. Execute Fatigue Analysis)

would be maintained as a separate entity, with each

individual activity being an instance of the activity class.

†

The classification structures can be developed by domain

experts, independent of the information model. This

avoids having to keep updating the model through the

addition of new classes and hence reduces the mainten-

ance burden.

†

It allows different types of classification to be main-

tained, by importing classes from different class libraries

into a uniform structure using a common model. These

can be regarded as model ‘plug-ins’.

The disadvantages are that the model structure can be

more difficult to understand because it is more abstract;

more effort is required to populate the system if there are no

readily available class libraries; and the implementation is

generally less efficient.

3.1.3. Use of associations

Although in object models, associations may be

implemented as attributes of the associated classes or as

ternary relationships, following the EPISTLE principles, the

IIM uses reification with separate association classes. The

main reasons for adopting this approach are:

†

It avoids the problem of many-to-many relationships, by

resolving them into one-to-many relationships to the

association entity.

†

It allows attributes to be maintained about the associ-

ations themselves, such as their beginning and end (if

terminated), descriptive information etc. This can be

important for recording life-cycle history and for audit

purposes. For example, this provides a systematic way of

recording time histories of connections of physical

objects and membership of parties (e.g. belonging to an

organisation), through the time-stamp attributes of the

corresponding associations.

†

It allows for further associations to be added to the

association entities, as may be required for recording

information about who created the association, why it

was created etc.

The top level entity class_of_associationrecords associations between two instances of class, and

association between two instances of individual. The

types of generic association which apply to entities in the

different sub-schemas are those for versioning, composition,

connectivity and succession, possession, involvement etc.

The classes of association can serve as templates for

defining associations between corresponding individuals.

For example, class_of_succession_of_activ-ity is a class_of_association which defines the

sequence of two classes of activity. It serves as a process

template for the corresponding association successio-n_of_activity at the individual level between two

actual activities that are carried out. As in Fig. 2, there is a

class_membership association between each such

class_of_association and its corresponding

association. Such instantiations may be enforced as

rules.

3.1.4. Composition and versioning

For composition, there are a number of different whole-

part associations in the model, applying to components,

activities, documents etc. These are equivalent to shared

aggregations in UML, and in the VR they are also

maintained as separate association classes. One of the

reasons for doing so is that information about the parts may

be required, independent of the whole; for a life-cycle

model supporting different views, information about the

constituent parts may need to be retained for other

applications; This fifth normal form approach supports

such component sharing.

Another important aspect of the model is the use of

versioning, for which generic associations also apply. Two

types are distinguished, as defined in the High Level

Framework:

†

Derivation: where a derived version is obtained directly

from a predecessor by means of an activity. This

association is at the top level of the model (i.e. attached

to thing), so applies to both classes and individuals.

Hence, for example, it can be used both to obtain

versions of a component_specification (a class)

through various design iterations, and of a document(an individual). Derivations include alternative versions

for different circumstances or conditions.

†

Version_succession: this is used to record that a

successor version is preferred to a predecessor for all

uses. This may be used to refer back to a previous version

of a procedure (a class_of_activity), or an old

component design that has since been superseded.

3.1.5. Attributes, properties and state

In the IIM, properties are regarded as having an existence

independent of any particular object. Property values

recording the state of an object, which in object models

are usually maintained in class attributes, are stored as

instances of a separate property class. The type of a

property is defined by class_of_property and a

possession_of_property association links specific

properties to the things to which the properties relate, in

particular to physical_objects, activities and states.

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190 179

This provides flexibility in recording properties and is

similar to the meta-model design pattern [29]. Further, sets

of property classes can be linked to other classes, to serve as

templates for defining the specific properties for a class. In

the example in Section 5.1 a set of material properties has

been defined for the purpose of a fatigue package evaluation

exercise. This is an example of a thing_set (as discussed

in Section 3.1.7) where, in this case, each set member is a

class_of_property (e.g. Fatigue Strength Coeffi-

cient). Having defined the set and attached it to the

material_structure_type in the class hierarchy,

it can then be selected as a template for viewing or editing

the required subset of properties for a given material, as

shown in Fig. 6. The state of a component can also be

described by a set of property values, as for the results of

computational simulation or physical testing.

3.1.6. Maintaining a network of associations

The IIM thus contains a network of associations which

link together the various sub-schemas, some of which are

shown in Fig. 3. The two-way arrows represent bi-

directional associations.

The associations can be navigated to determine, for

example, which parties have been, or are, involved in a

given activity, or which activities a given party has been, or

is, involved in—and similarly for components, documents

and state. In general, there are several such associations

between the different sub-schemas, and associations may

apply at both the Class and Individual levels (hence the

omission of the association labels in Fig. 3). The temporal

nature of associations at the class and individual levels is

discussed in [30].

3.1.7. Collections

The last sub-type of thing shown in Fig. 1, a

thing_set, is used to identify an unordered set of

arbitrary things. The members of the set are identified

through separate associations. This is similar to the notion of

a container in OO design, where there are no special

Fig. 3. Part of the assoc

relationships between the set members. For example, it can

be used for a collection of documents or a set of component

characteristics.

3.2. Activities

The IDEF0 formalism [31] has been used for recording

the involvements in activities as role associations. IDEF0

distinguishes between inputs, controls, outputs and mech-

anisms. An input is something which is transformed by an

activity; an output is the result of a transformation or

something produced by an activity; a control is a constraint

governing an activity execution; and a mechanism provides

the means to accomplish or support an activity. In the IIM,

this formalism is applied at both the class and individual

levels. At the class level, the instantiation specifies the type

of things expected to fulfil the various roles; the roles are not

limited to actors, but include document, physical_object,

party and program classes. At the individual level, the

model records information about how an activity is actually

conducted. There are also composition and succession

associations at both the class and individual levels. At the

class level, process types, which are a sub-type of

class_of_activity comprised of activity classes, can serve

as templates for conducting process instances.

Best Practice documents can also be assigned roles in

activities and this forms the basis for the retrieval of general

advice in the BPA. Further associative links to specific

document resources relating to particular component

characteristics can enable filtered information retrieval, as

described in [3].

As shown in Fig. 3, activities are linked to state so that

information about the states through which a component

passes during an activity can be stored. As sets of property

values can be recorded for the different states, detailed

engineering information can be retrieved for an activity.

This is in contrast to traditional workflow applications,

which generally just record the status of an activity

iations network.

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190180

(e.g. as for an activity instance in the Workflow Manage-

ment Coalition (WfMC)8 model).

3.3. Components and features

Information about components and features is stored

under class_of_physical_object in Fig. 1, with 3

principal categorisations:

Design types: Apply to generic classes of components

and features, as distinct from specific designs, with the aim

of facilitating reasoning about components. The compo-nent_type class has specialisations for form and

function. In the automotive mechanical engineering

context, typical form classes are solid parts, shells, plates

etc. while the top level function classes are for body parts,

suspension and powertrain components. Only a shallow

form hierarchy was required for INTEREST, but the

function hierarchy was reasonably well specialised. This

was mainly because the function hierarchy was used as the

primary search route for determining the matching contexts

in the BPA. The classes used in populating the IIM function

hierarchy may be regarded as generic component part types

classified according to function, being specialisations of

such explicit high level functional types.

As with form and function, feature_type defines

generic types such as holes, fillets and bosses. The main

focus has been on geometric features, loosely described as

prototypical shapes with some engineering significance.

There are many different views of what constitutes a feature

and corresponding different feature taxonomies. Top level

distinctions include design features, either based solely on

form, or in combination with other characteristics such as

material, tolerance and surface finish; function features,

indicative of purpose; and manufacturing features which

provide more detailed information about the manufacturing

operations and tools to be used for process planning. The

population for feature types has focused on function and

design features, though the VR does not impose any

particular feature classification and the system can be

populated according to the required taxonomy.

Design specifications: These are used for specific designs

for which property values are defined, again with a top level

distinction between components, corresponding to part

types, and features. These specifications are specialisations

of the generic design types; e.g. a steel connecting rod is

defined as a specialisation of the connecting rod function

class and the steel of which it is made. The properties of a

design (e.g. dimensions, mass) are obtained through the

possession_of_property association.

Individual components: These are actual manufactured

parts for which information may need to be retained, such as

for prototype components used in mechanical testing and

actual in-service parts for maintenance applications.

8 http://www.wfmc.org/

Separate property values can be maintained for individual

parts to record variation in relation to design tolerances.

3.3.1. Compositions and connections

Different composition and connection associations can

be maintained for components, features and machines. For

components a breakdown is obtained for whole/part

associations for classes of function or machine,

while a Bill of Material (BOM) parts breakdown is obtained

for composition associations applied to component_-specification. These breakdowns are independent of

the component specialisation hierarchies. Machines have

been included mainly for recording their involvement in

activities, rather than for their functional breakdown. The

predominant breakdown aspect (functional or structural) is

generally governed by the domain and application view-

point as discussed in [32] and functional hierarchies can be

grounded on behaviour as in [22,33]. For features,

composition associations are used for sub-features. There

are further composition associations for recording the

features of a component and for the composition of

materials.

For connections, generic classes are defined with their

own hierarchy; e.g. for mechanical engineering, top-level

classes include welding, bonding and mechanical fastening.

Connection specialisations are generally based on the

connection forming process. When a particular class of

connection is recorded between component parts, the type

of connection is defined by one of these generic classes, e.g.

spot weld. For features, connection associations can be used

for recording feature graphs.

3.3.2. Design representations

For each component specification, references to different

model representations can be maintained, such as for solid

and wireframe models and finite element meshes. For the

INTEREST requirements, only references to documents

containing the different CAx model representations and

analysis results were stored in the VR. It is possible to store

certain analysis information directly in the VR, though; for

example, key results for component fatigue lives can be

stored, as illustrated in Section 5.2. The IIM could be

extended to incorporate model representations for geome-

try, topology and field property variation, such as gener-

ically specified in STEP Part 107. Another neutral model for

CAx integration based on features [34] combines design by

features and feature recognition, enabling different views to

be extracted for different applications.

3.4. Documents

The Document schema covers both references to external

document resources and to document content (text, images

etc.) held in the VR, with corresponding separate generic

classes as shown in Fig. 1. The former corresponds to the

PDM treatment of documents, typically as collections of

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190 181

files, while the latter corresponds to Content Management

systems where actual document components and their

assembly structure are stored. The recording of document

metadata has been based on the Dublin core parameters9,

providing details of document title, location, author, date,

language etc. A number of other associations between

documents are defined, including compositions for break-

down structure; references to related documents, such as for

tracing the document trail back through a process; and

derivations for version management. Documents can have

several different classifications, so they can be located using

alternative drill-down routes through the class tree of the

Data Manager. Meta-data can be obtained by selecting a

document in the list of individuals for the current class.

Alternatively, the repository can be searched directly for

documents matching different meta-data combinations.

There is a 1:many association between document_-content and document, since the same content may be

stored in different document containers, e.g. in Word or pdf

documents. Document abstracts are stored in a separate

content class. Other associations link to the subject(s) of a

document, or a document content component. The former is

used in the BPA for content-sensitive searches. To date,

development has focussed on the document level and the

VR only provides limited support for content management.

3.5. Populating with class libraries

3.5.1. Standard schemes

The VR can be populated with classes according to the

IIM schema, either by importing classes from external class

libraries in RDF/XML format or by manually adding classes

using the Data Manager. Classes could be imported from

standard class libraries such as ISO 13584 (Plib [35]), and

ISO 15926 (STEPlib [36]). Some STEP APs have links to

these parts libraries. Component brokers are providing

catalogue management systems for integrating and con-

solidating data from different component suppliers. It

should be possible to import parts data from such systems

in standard form, either directly into the VR or via a PDM

system.

Whilst these standards should have increasing impact on

mechanical engineering, there are many other classification

schemes for mechanical parts and materials. In the

manufacturing sector, there are long established schemes

for defining overall part characteristics, in particular Group

Technology (GT) schemes. In GT, components with similar

design and/or manufacturing attributes are grouped into

families, with information about parts typically condensed

into 10–20 digit codes, based on simple chain type,

hierarchical and various other schemes. These codes

require more detailed interpretation for mapping to the

IIM. A given GT code can be instantiated as a

9 http://dublincore.org/

component_specification class, which is then

populated as various specialisations of physical_ob-ject classes, derived from the code. A similar reverse

translation for GT code generation from an Object-Oriented

STEP database has been reported based on the MICLASS

GT scheme [37]. Further, the GT codes incorporate process

planning information, which can be defined as classes of

activity linked to the component class.

Links to material libraries can also involve similar

interpretation and mappings. For exchanging material data

over the Internet using XML, there is the general

MATML10, as well as more specific languages such as

SML11 for steels.

3.5.2. Basis for classification

With its generic structure the IIM should be capable of

integrating these schemes through various mappings,

though as of yet, only limited integration has been validated.

Importing and exporting component data can generally only

proceed semi-automatically, with some guidance from the

user, due to the difficulties with multiple classification, and

with interpreting GT codes. Component classification can

be based on different component aspects such as function or

role (e.g. rotating part, suspension part), construction

material (e.g. cast iron part), characteristics (e.g. high

speed shaft), shape (e.g. oval bearing), location (e.g. driven

end bearing), and other aspects as discussed in STEPlib.

Reasoning about component hierarchies is facilitated by

following classification principles, such as those of identity,

unity, rigidity and dependence, described in [25], following

a philosophical analysis to developing well-founded

taxonomies. More complex notions can then be expressed

as combinations of higher level classes and properties,

which in turn should improve knowledge-based search and

reuse, as in applications like the Best Practice Advisor.

However, such subsumption principles have not been

applied in the VR. This is partly to avoid constraining

‘natural’ classifications as engineers extend the specialis-

ation hierarchies, and also to enable different drill-down

routes according to characteristic, as in faceted classifi-

cations. This particularly applies to the physical_object

schema, but also to other aspects of the model not specific to

engineering. For example, applying subsumption principles

typically results in ‘person’ being a subtype of ‘living

thing’—‘animal’ etc; i.e. this gives a biological viewpoint

but for enterprise applications subsuming under party is

quite natural, since person and organisation share

common characteristics. Another contrast concerns the

treatment of roles. In Welty and Guarino’s analysis, roles

are anti-rigid (a ‘property’ not essential to all instances of a

class) and dependent. Following the EPISTLE approach,

10 http://www.ceramics.nist.gov/matml/matml.htm11 http://xml.coverpages.org/steel-SML.html

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190182

roles are treated as separate associations in the IIM,

supporting their temporal nature, as outlined in Section 1.

3.6. Relation to RDF and Topic Maps

As both RDF and Topic Maps are based on graph data

models, they have a structural similarity with the IIM and

hence provide a route for interoperability. For RDF and

RDFS the graphs are directed, with labelled arcs, while in

Topic Maps the arcs have an implicit direction through the

roles of the nodes at each end of the arc. Another important

distinction is that Topic Maps are ‘fully’ reified, whereas for

RDF, reification statements are generally only used as and

when required; this has been called ‘pre-emptive’, as

opposed to ‘lazy’ reification [38]. In this respect, the IIM

more closely resembles Topic Maps than RDF, as indicated

by EPISTLE principle 3 in Section 3.1.1.

3.6.1. Comparison with RDF(S)

Repository systems such as Sesame12 and RSSDB13 are

now available for persistent storage of RDF data and RDFS,

as summarised in [7]. The IIM and VR were not designed

with RDF(S) in mind, but reasonable interoperability should

be achievable and such feasibility has been tested through a

limited VR import capability demonstrated for EPISTLE

process plant data. At the RDF data level, the translation is

rather more involved due to the various alternative serial-

isations that have to be catered for, and due to the need in

some cases to create additional objects to satisfy the IIM

structure. The use of RDF for EPISTLE style data is

discussed in [39].

3.6.2. Comparison with topic maps

In some respects the IIM forms a closer match with the

core of the Topic Map paradigm due to the similar

reification approach, though Topic Maps have additional

modelling superstructure not supported by the IIM.

As a topic can be about anything that can be mean-

ingfully referred to, a topic may map to a class (e.g.

aluminium) or an individual (e.g. Land Rover) in the IIM.

Topics can be classified as topic types, which correspond to

IIM model_classes. If a topic corresponds to a class, a

new IIM specialisation relationship may be required for the

topic type. This also applies to Topic Map associations,

which can also be typed. Topics can have one or more

occurrences providing links to related information

resources. These also have a counterpart in the IIM, to the

association, description_by_document. The Topic

Map occurrences can have roles, which correspond to

IIM model classes, as for domain and range in RDFS.

Hence, in principle, there should be a reasonable degree of

inter-operability between the core Topic Map structure and

12 http://www.openrdf.org/13 http://www.forth.gr

the IIM, though Topic Maps provide some facilities, mainly

relating to naming, identity and scope, which are not

supported by the IIM at present.

4. Implementation of the Virtual Repository

The IIM has been implemented using an Object

Database, Poet 14, with client-server access over the Internet

or Intranet using Java technology. The information model

was originally specified in textual and graphical form using

STEP Express and subsequently converted to UML using

the Rational Rose15 modeller. For Java, the coupling

mechanism between Rational Rose and Poet was used

whereby class headers are generated for each schema class

and the Poet pre-compiler, PTJAVAC, inserts basic

persistence code, generates executable byte code and

updates the Poet dictionary and database. In practice this

procedure was extended with further code generation

utilities to facilitate the Java Remote Method Invocation

(RMI) implementation.

4.1. System architecture

Fig. 4 shows an outline of the system architecture with

the 3 client applications: the JDS, BPA and Data Manager.

The heart of the VR implementation is the Business Object

Library (BOL), with which these clients communicate via

RMI. The BOL exports interfaces for interaction with

clients, and provides implementation methods defined in

these interfaces. The BOL communicates with the Poet

Persistence Layer for low level storage and retrieval. In

addition to direct storage in the object database, Poet also

provides output to relational databases, such as Oracle and

SQL server, via the Poet SQL Object Factory gateway,

though in INTEREST only a Poet database was used.

The VR Repository contains references to other docu-

ment resources and databases. To date the VR has just

served as a passive repository for recording and retrieving

process and component information. Key information about

activities is recorded, but methods have not been defined for

invoking activities directly. In INTEREST, the separate

Tool Manager was used for this purpose.

4.1.1. Links to the job description system (JDS) and best

practice advisor (BPA)

Details of the architecture of the JDS and BPA sub-

systems, as shown in Fig. 4, have been given in [2,3],

respectively. The JDS, which runs in a Web Browser, is

based on population of XML templates for creating a job log

through enactment of a process. Wizards which interrogate

the VR are provided for initial population and for archiving

14 http://www.poet.com15 http://www-306.ibm.com/software/rational/

Fig. 4. Outline of system architecture.

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190 183

the process logs, with a mapping between the VR business

objects and the XML elements. In the case of the BPA,

information retrieved from the VR is substituted into Cold

Fusion16 templates using the CFX_J Java API and output as

HTML pages. The BPA can be run as a stand-alone client or

linked to the JDS. In the latter case, the relevant context,

such as the current task and the component characteristics, is

passed directly from the JDS to the BPA via Http. The BPA

uses this context information to compile customised

advisory pages from the VR archive. Hence there is a

close coupling between these sub-systems with the aim of

capturing new knowledge during process execution in the

JDS (‘learning by doing’) and indexing the knowledge in the

VR for subsequent recycling through the BPA. A further

challenging aim is to try and conduct this process in a

relatively unobtrusive manner, shielding the engineers from

the information representations and storage mechanisms

and minimising the additional documentary effort.

4.1.2. The Business Object Library (BOL)

The schema classes shown in Fig. 1 have corresponding

classes in the BOL, each with an interface wrapping

defining the remote interface of the VR server. There are

two important additional classes in the BOL. Firstly, a

controller class provides access to the business object

classes and also object factory facilities for creating,

querying and deleting business object instances, including

execution of general OQL queries. Secondly, a root class is

added at the top of the business object hierarchy to provide a

number of generic management functions. These include

methods to remotely read/write the fields of a derived

remote object, using Java reflection to interrogate the fields,

16 http://www.macromedia.com/software/coldfusion/

and maintenance and access to the forward and backward

references used in the navigation of relationships between

objects. For classes at the top of the BOL hierarchy (e.g.

thing and model_class), generic methods are pro-

vided such as for the creation, access and management of

relationships. For those lower down the hierarchy, more

specialised methods are provided according to the generic

type; e.g. for obtaining documents involved in an activity or

the features of a component.

4.2. Data Manager features

The Data Manager is used for populating the VR and for

browsing and searching its contents. This application is

based on the BOL with RMI communication to the server

and, being written entirely in Java, is portable across

different hardware platforms. The display area is divided

into five permanent adjustable panels. The panels display

the class hierarchy; individuals for the selected class in the

class panel; attribute values of the selected class or

individual; an association tree based on a selected class or

individual; and a graphical workspace for displaying and

manipulating the various relationships between objects, viz

their specialisations, class memberships and associations.

For certain options further temporary windows are used,

such as for displaying query results sets or comparing

different breakdown structures and form-based interfaces

are provided for generating queries. Some of the main Data

Manager features are:

†

Browsing: In addition to ordinary navigation through the

class tree, options are provided to reverse the natural

browsing order to navigate up a hierarchy, and to reset

the tree root to focus on a selected branch. Similarly for

associations, starting from a given root object, links to

other objects can be explored in the Association panel,

following either the forward or reverse direction, as in

Section 5.1. For an individual or component part type, in

any of the panels, a point and click option is provided for

obtaining associations and properties of the object. For

composition associations, breakdowns can be displayed

in a separate window. This can be used for BOM for part

types, activity breakdown for processes, displaying

document structure, composition of materials and

features etc. Collections can also be viewed indepen-

dently in separate windows.

†

Searching: Simple query options are provided for finding

a class or individual by name or property value

constraint(s). More detailed queries can be generated

for locating components by means of a combination of

characteristics, documents through their meta-data or

activities with respect to their process type, roles and date

etc. Searches can be applied globally, according to the

type being searched, or the extent can be limited

according to the location in the class tree. In some

cases the sub-class constraint also applies to the search

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190184

parameters, as discussed in Section 5.2. The results of a

search can be saved as a collection, classified under

thing_set, for later recall. This allows for future

extensions for set operations.

†

Combined Browsing and Searching: For browsing,

navigation becomes more difficult as the population

expands, while for searching it is often useful to see the

results in situ in the class hierarchy. Hence a combined

browsing and search facility is provided where the class

tree can be automatically opened to display the results of

a search, either directly or by making a subsequent

selection in the results window where a matching set

occurs.

†

Editing: Forms and tables are provided for creating and

editing classes and individuals. Some options just

provide simple panels for directly creating and editing

objects. Others provide more elaborate forms which

when processed, not only change object attribute values,

but also generate required relationships. They can be

regarded as business object interfaces in the OMG sense,

in that they hide the complexity of the low level storage

mechanism.

†

Filtering: As there are a considerable number of

association types, it can be useful to restrict displays to

certain types to focus on given aspect(s) of the data.

Hence filters are provided for objects displayed in the

Workspace, Association and Collection panels.

†

Caching: For efficiency and additional user control,

client-side caching is used for downloaded objects and

for editing. Edit updates are not transmitted directly to

the server but are cached until the user makes an explicit

commit. This provides some editing license, in that edits

can be cancelled prior to a commit, and also helps to

reduce network traffic. The search options take account

of which objects have been cached on the client.

In addition, for interoperability purposes facilities are

being developed for importing and exporting data to/from

the Repository for a number of standard formats and a direct

link to external servers is provided via JDBC (Java Database

Connectivity).

5. Examples of data manager application and retrievalfeatures

The initial implementation of the INTEREST infor-

mation model comprises about 50 activity classes corre-

sponding to tasks carried out during a durability analysis

process and, for testing purposes, a similar small number of

classes of form, function, material, fabrication (manufactur-

ing process) and surface finish type. Each set of classes is

defined in a user-defined hierarchy extending the relevant

schema-defined inheritance hierarchy, shown in Fig. 1. For

test purposes, a maximum of 3 or 4 user-defined specifica-

tion levels have been used in each case. For example, under

Function, the user may define specialisation levels for

Powertrain Components, Rotating Parts and Crankshafts. In

practice, for different industrial applications, base-line class

libraries are expected to be provided to initialise the system,

which can then be further customised and extended

according to local development requirements.

For each activity class a topic description is provided and

one or more pages of general best practice have been

indexed for the BPA. Context specific information has also

been provided for some high-level part classes (e.g.

powertrain components, rotating shafts or metal cast parts)

and for a number of demonstration parts (e.g. crankshafts,

connecting rods, steering knuckles). BPA relating to a

number of features (e.g. bolted joints, spot-welds, riveted

joints, fillets, oil holes) is given for those activities for which

the features are important.

For the typical Component Development Process that has

been used for fatigue studies in INTEREST, the breakdown

into 50 activity classes with 3 levels of specialisation is

considered to be quite adequate for general use. This typical

process spans the design, stress analysis and fatigue analysis

stages, with various pre and post-processing steps at each

stage. As the activity classes are user-defined, as opposed to

being hard-coded in the schema, process variants can be

used as required. In one such field trial the process has been

extended into the manufacturing domain incorporating

activities employed by a component supplier such as for

casting simulation and mould manufacturing. Further,

completely different processes can be supported by supply-

ing a different activity class library.

In contrast to the activity set, in industrial applications a

larger class set will commonly be used for some of the

component characteristics. For example, a typical auto-

mobile consists of several thousand parts with the number of

separate functions being much greater than 50. The function

subsets used to date have mainly consisted of those most

prone to fatigue, which has been the main focus of the

research effort. For other applications, such as component

maintenance, much larger function sets would be expected,

and more detailed class specialisation would also be

common.

5.1. Browsing and searching repository data

With the modular system architecture, the Data Manager

can be used in conjunction with other client applications,

such as for populating the repository for use with the BPA.

The Data Manager also provides a range of navigation and

search options.

For example, Fig. 5 shows a display for retrieving

information for fatigue analyses of a steering knuckle

component, using a number of different commercially

available packages for comparative evaluation. The class

panel shows a list of activity classes with ‘Execute Fatigue

Analysis’ selected. The adjacent central panel shows part of

the listing of the actual fatigue analyses carried out, with an

Fig. 5. Data manager display for fatigue analysis retrieval.

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190 185

analysis using the FESAFE package selected for a

component BG2.

Search queries can be made, as in Fig. 6, where the ‘Find

Part Types’ option has been used. This shows a search for a

steel steering knuckle and subsequent display of the

characteristics of one of the matching results in the right-

hand panels. The selection, BG2, is shown highlighted

under Component Specification (synonymous with Part

Type) at the bottom of the class tree viewport. The part type

can also be shown in the other branches of the class tree for

the classes of which it’s a specialisation. In Fig. 6, its

position in the Function hierarchy is shown. For this

illustrative case, just a flat Component Specialisation list has

been used, but a separate design or product type classifi-

cation may be used. A BOM component assembly option is

provided in the View menu, with the breakdown and

cardinalities displayed in a separate window, similar to the

task list in the right-hand corner of Fig. 5.

In this example the individuals in the central panel are

actual prototype parts that have been subject to physical

testing. The corresponding associations in the Associations

panel include several documents describing or referencing

the component and a picture of the component has been

selected and displayed in another window using the Java

HTML viewer.

More elaborate queries can be constructed using

combinations of component characteristics and properties,

with various options being provided for picking character-

istics from selection lists. For creating and editing part type

data, a similar panel as in Fig. 6 is provided, with a variety

of options for filling the form.

5.2. Comparing analysis and test data

The purpose of the foreground list panels is to assemble

attributes with related information from other objects into

Business Object type views, as shown in Fig. 7. This

compares a physical test with another fatigue analysis of the

BG2 component. The picture in the bottom left-hand corner

shows failure points for mechanical tests of the component

and the fatigue life and failure location for first test is given

at the bottom of the left-hand panel. These panels include

some related information obtained by following paths

through the association network and by making some

limited inferences where needed. For example, in this case

both activities form part of the same process, as indicated in

the second field on the panels, with the part type being

studied just being linked to the process. In some cases the

actual process that has been executed may be important,

both for audit purposes and for evaluating the results.

Fig. 6. Searching for component part type and displaying characteristics.

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190186

6. Evaluation

The INTEREST sub-system outlined in Section 5 is at a

research prototype stage. Such examples provide a basic

verification that the model and the VR software should be

capable of meeting the industrial requirements. There are a

number of aspects of the model that need review and

refinement though, such as more general support for

property, loading and location data. As yet only ‘simple’

single-valued properties have been used, as in the above

examples. This was sufficient for the needs of INTEREST,

given the virtual nature of the repository where detailed

results are referenced via documents. However, for more

general engineering support and possible lower level

integration (e.g. as discussed in Section 3.3.2), a consider-

ably more detailed property and state schema would need to

be implemented. Similarly for wider application, the

location schema would need to be extended to incorporate

more detailed network and geographic information; for our

purposes, only administrative location data was needed for

parties and machines. For recording loading data, the IIM

contains a class_of_loading as a sub-type of

class_of_activity, since in real-world modelling,

loading is itself an activity. However, given the importance

of loading for fatigue and the need to record a variety of

loading characteristics (e.g. for mode, regime, direction,

phase, sequence etc.), there may be a case for making it

more prominent as a separate top-level class, with a loading

specification, akin to the design specification as described in

Section 3.3, in order to better match the user’s perception.

This would actually be a minor change to the schema since

other loading associations, such as for applying loading

classes to analysis activities would remain in tact. In the VR

software, improvements are also needed for supporting

properties, such as for assigning appropriate default values

for inherited properties.

The adequacy of the VR system for the needs of the

Best Practice client has been reviewed in [3] and

generally found to be satisfactory, though some extensions

for recording decisions in relation to their impact on

downstream tasks has been proposed. The nature and

reasons for the decisions are recorded in the Job

Description System, though further information on the

general applicability of the decisions and the significant

context factors needs to be captured. For certain tasks, the

Best Practice Advisor may need knowledge of previous

decisions made, in order to customise advice for the

current task.

Fig. 7. Comparison of physical testing and fatigue analysis of steering Knuckle.

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190 187

6.1. Benefits of the development approach

Experience to date has shown that the VR offers a

number of benefits, though being a prototype some of

these have only been partly realised. The business benefits

of the BPA have been discussed in [3], most of which apply

to the VR.

6.1.1. Flexibility

A key objective of the IIM has been to provide an

integrated process and product information model that

provides flexibility for population by users. The aim is to

achieve a relatively stable repository which should be well

equipped to accommodate business changes and extensions

to new application areas. Because of this versatility, the VR

should form a suitable basis for integrating data from

disparate sources. This has already been borne out to some

extent, though as yet only limited inter-operability features

are available. Whilst some ODBMS, such as Orion and

Itasca, provide sophisticated facilities for versioning and

schema evolution, this may still entail interaction between

IT support staff and engineers. An aim of the IIM design has

been to reduce the need for such support.

The VR also provides flexibility in being able to combine

management of structured and unstructured data. Searches

of structured data can be combined with navigation to

related information through ‘free’ exploration following the

association links. This provides a combination of features

from ‘conventional’ database and document management

systems. The software also provides versatility in displaying

retrieved information for direct comparative purposes,

taking advantage of the OO features.

6.1.2. Reuse and data mining

As the information in the VR is related in a systematic

and consistent manner, it should facilitate design reuse and

modification. The VR could be used for data mining clients

in searching for patterns of characteristics or behaviour from

archived material. As discussed in [5], fatigue analysis is the

subject of active research, such as attempting to establish

the source of discrepancies between different analysis

applications and techniques, and between analysis and test

results. These are being investigated from a numerical

analysis standpoint, but further insight might be gained by

applying data mining techniques to the design histories and

using the VR as a test-bed for hypotheses.

Software reuse is also facilitated through generic

methods provided in the Business Object Library as

described in Section 4.1.2. The library provides an open

Application Programming Interface for accessing the VR,

reducing potential duplication in client applications.

17 http://www.w3.org/TR/owl-ref/

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190188

6.1.3. Life-cycle management

With the clear distinction between classes and individ-

uals and the systematic approach to recording design and

analysis histories, the IIM is well-suited to life-cycle

management. This has been partially verified through

coupling with the Job Description System, though further

facilities are required in the VR for configuration and

version management. Although this research has focussed

on design and analysis, given the generic approach, the

scope could be extended to garner experience from down-

stream manufacturing, distribution and operation, providing

additional life-cycle feedback to new designs. For example,

clients may inform designers of maintenance problems or

environmental impact factors that might be relevant to new

designs.

6.2. Drawbacks

It is felt that the main drawbacks are those common to

other generic software efforts. Firstly, the initial develop-

ment requires significant effort due to the generic consider-

ations, yet does not produce direct application benefits in the

short-term. Secondly, there is some performance penalty for

the flexibility provided. The retrieval methods naturally

tend to be more complex than for more specific applications,

due to following the network of associations. For relational

implementations there will also be some overhead for the

table joins needed to satisfy queries. Whilst the performance

has been deemed satisfactory for the INTEREST prototype

with the Best Practice and Job Description clients, only

small class libraries (w100 classes per generic type) have

been used; e.g. with the focus on durability analysis, the

component library has been limited to those component

types prone to fatigue.

Although we have closely followed the EPISTLE

guidelines in developing the IIM, we have not applied

reification universally, in order to minimize the processing

and storage overheads. This approach is similar to that

followed by Lenat and Guha in the development of the

second phase of Cyc where they supplied criteria [40] for

deciding when to reify a new concept (collection), such as,

only when there are several important properties to assert

about it. Nevertheless, there are likely to be some further

trade-offs between model flexibility and performance, as we

scale up to supporting larger repositories. Further trials are

needed to assess such scalability.

The generic nature of the model leads to possible

alternatives for some aspects of the population, requiring

additional retrieval checks. Care must be taken in mapping

to the generic form, since different semantics may be

associated with the generic terms in different view models.

The use of multiple classification, multiple inheritance and

some implicit population also has to be catered for. Such

complications are avoided, or at least reduced, in more

restrictive classification systems and more specific ‘snap-

snapshot’ applications.

7. Industrial application

The VR prototype has served as a concept demonstrator

of the generic modelling approach. Further development is

needed, both in terms of model refinement and in providing

more comprehensive Business Object coverage. As pre-

viously indicated, other areas of the system requiring further

development for industrial application include:

†

Constraints on certain aspects of the population, or at

least some additional constraints need to be formally

defined in the model rather than being embedded in

procedural code. This would take development into the

realm of ontological engineering, with support for

OWL17 being a first step.

†

Improved inter-operability: the VR core needs to provide

a variety of links to related systems (CAx, PDM, material

databases etc.), so that the VR clients can be better

integrated with existing systems; currently, only limited

links are available. Further, information in the repository

should ideally be displayed in terms familiar to

individual clients, since different terminology may be

used for the same repository items, for different view-

points and cultures.

†

In addition to such terminological variants, better support

is needed for view dependencies. This applies mainly to

the physical_object schema, such as for functions

and features.

†

Further work at the persistence level is needed for

security and access control, transaction management and

improved support for different database

implementations.

7.1. Wider application

Although the VR has been developed for the

automotive industry, because of its generic design it can

be applied to other industrial sectors. For other engineer-

ing contexts, it should be possible to use the schema

almost directly, with appropriate renaming of some

schema classes, and substitution of appropriate class

libraries for the domain. For example, new sets of

components and properties can be imported according to

the industrial sector, such as for shipbuilding, aerospace

and construction. Further, in applications such as anat-

omy, genetics and molecular modelling, the division into

Form, Function, Material and Feature etc. could be

directly applied. In the anatomical field, a recent

publication [41] describes an extension of the Protege

system using reified relations and metaclasses, focussed

on part-of relations for the body, following much the same

approach as described in Section 3 for the IIM. Where

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190 189

there are no suitable domain class libraries, though,

building the required level of detail may prove time

consuming, as has been found when constructing some

ontologies from scratch. In such situations, the use of new

semi-automated, NLP ontology building tools may help

with the population process.

8. Conclusions

We have provided an overview of the INTEREST

integrated product and process life-cycle information

model, used as a basis for a Virtual Repository for

mechanical engineering. The core model is based on the

EPISTLE generic entity modelling approach, using meta-

classes to cater for a diverse range of applications, and

making extensive use of reification to capture the complex-

ities of the associations, particularly for recording time

histories and composition relationships. Whilst EPISTLE

has been focussed on process plant applications, our

prototype implementation suggests this approach is also

viable for supporting automotive component development.

Although approaching the development from an infor-

mation modelling standpoint, the resulting model has

similar characteristics to some ontologies used with

frame-based, knowledge representation systems.

In implementing the Repository we have applied

standard OO modelling and Web technology. Although

we have used the Poet Object Database for the prototype

implementation, it should be possible to implement the

system using other types of relational, object and object-

relational databases. Our aim has been to hide some of the

modelling complexities, with regard to reification etc. so

that the system can be populated by engineers without

having to understand the model details.

In INTEREST, we have demonstrated how the repository

can be used in conjunction with a Job Description system for

capturing process information, and a Best Practice system

for furnishing context-sensitive advice based on accumu-

lated information stored in the repository. This provides a

range of business benefits including productivity improve-

ments by making relevant knowledge more readily

accessible; reduction in costs by avoiding re-solving the

same problem and avoiding previous mistakes; improved

knowledge sharing in general; and support for technical

auditing.

Although the IIM has been designed to support fatigue

studies in INTEREST, it is believed that the generic

modelling and modular implementation that has been

adopted should be more widely applicable to the

integration of process, product, document and engineering

data management, a view that is supported by early

experimental work applying the IIM to process plant

design.

Acknowledgements

The authors gratefully acknowledge the support of DG

III of the European Commission for the INTEREST project

under the ESPRIT/AIT initiative. They are also grateful to

their colleagues in the project for their contributions to this

paper.

References

[1] Leal D, Brown D, Remzi-Sirri E. The INTEREST Information Model,

INTEREST Integrated environment for durability and Reliability

design support Tools, ESPRIT AIT Project. 25584; Deliverable

D2201; 1999.

[2] Laan DJ, Braakman EJ, Kusters T, Devlukia J, Liu Y, McMahon CA,

et al. The INTEREST project: a learning by doing approach for

making mechanical engineering a repeatable and auditable process.

Proc PDT Days 2000, ESTEC Noordwijk, The Netherlands; 2000. p.

205–214.

[3] McMahon CA, Liu Y, Crossland R, Brown D, Leal D, Devlukia J. A

best practice advice system to support automotive engineering

analysis processes. Eng Comput 2004;19(4):271–83.

[4] Boss Quattro Specifications, v4.1, Samtech, Liege. http://www.

samcef.com; 2001.

[5] Nowack H, Hanshmann D. Cooperative component development and

significance of fatigue, Fatigue 2002 conference proceedings, Stock-

holm, Sweden, June 2002, vol.2, Engineering Applications, Keynote

Address.

[6] Bargmann H. The role of stochastic modelling in problems of fracture

and fatigue, ASME 1999 mechanics and materials conference,

VPI&SU, Blacksburg, VA, USA; 27–30 June 1999.

[7] Ding Y, Fensel D, Klein M, Omelayenko B. The Semantic Web: yet

another hip? Data Knowl Eng 2002;41:205–27.

[8] Reingruber MC, Gregory WW. The data modeling handbook—a best

practice approach to building quality data model. New York: Wiley;

1994.

[9] Dullea J, Song I-Y. A taxonomy of recursive relationships and their

structural validity in ER modelling. In: Akkoka J, Bouzeghoub M,

Comyn-Wattiau I, Metais E, editors. Lecture notes in computer

science 1728. Paris: Springer; 1999. p. 384–9.

[10] Wand Y, Storey V, Weber R. An ontological analysis of the

relationship construct in conceptual modeling. ACM Trans Database

Syst 1999;24(4):494–528.

[11] Sugumaran V, Storey VC. Ontologies for conceptual modelling: their

creation, use and management. Data Knowl Eng 2002;42:251–71.

[12] Davies JFensel DHarmelen FV Towards the semantic Web: ontology

driven knowledge management . Wiley, New York; 2002http//www.

ontoknowledge.org/ (Ontoknowledge home page).

[13] Missikoff M, Navigli R. Integrated approach to web ontology learning

and engineering. Comput (IEEE) November 2002;60–3.

[14] Scheer A-W. Architecture of integrated information systems:

foundations of enterprise modelling. New York: Springer; 1994.

[15] Silverston L, Inmon WH, Graziano K. The data model resource book.

A library of logical data models and data warehouse designs. vol. 1.

New York: Wiley; 1997. Silverston L, Inmon WH, Graziano K. The

data model resource book. A library of logical data models and data

warehouse designs. vol. 1. New York: Wiley; 2001.

[16] Eriksson H-E, Penker M. Business modeling with UML: business

patterns at work. New York: OMG Press/Wiley; 2000.

[17] Owen J. STEP: an introduction. Winchester: Information geometers;

1993.

[18] Gielingh WF. General AEC Reference Model (GARM), TNO

building and construction research, BI-88-150; October 1988

D. Brown et al. / Advanced Engineering Informatics 18 (2004) 173–190190

[19] Dreyer T, Giannini M, Lambrecht D, Laresgoiti I, Selvik E, Weber T.

Achievements of the Esprit IV project 22297 ElectroNet—a project

closing report. Eur Trans Electr Power, ETEP 2001;11(3):163–71.

[20] Ansi/X3 architecture: standards planning and requirements committee

(Sparc); 1975.

[21] Szykman S, Racz JW, Sriram RD. The representation of function in

computer-based design. Proceedings of the 1999 ASME design

engineering technical conferences, September 12–15, Las Vegas

1999. DETC99/DTM-8742.

[22] Yoshioka M, Umeda Y, Takeda H, Shimomura Y, Nomaguchi Y,

Tomiyama T. Physical concept ontology for the knowledge intensive

engineering framework. Adv Eng Inform 2004;18(2):95–113.

[23] Pease A, Niles, I. Towards a standard upper ontology. Proceedings of

the 2nd international conference on formal ontology in information

systems, FOIS-Oct; 2001, p. 2–9.

[24] Bernaras A, Laresgoiti I, Corera J. Building and reusing ontologies for

electrical network applications, Proceedings of the European

conference on artificial intelligence, ECAI; 1996 Buddapest;

Chichester UK:Johnwiley; 1996, pp. 298–302.

[25] Welty C, Guarino N. Supporting ontological analysis of taxonomic

relationships. Data Knowl Eng 2001;39:51–74.

[26] McGuinness D. Ontologies come of age, in the semantic Web, why,

what and how. Cambridge, MA: MIT Press; 2001.

[27] Fridman N, Fergerson RW, Musen MA. The knowledge model of

Protege: combining interoperability and flexibility. Proceedings of the

European knowledge acquisition workshop (EKAW). New York:

Springer, LNCS; 2000 p. 17–32.

[28] Kozaki K, Kitamura KY, Ibeda M, Mizoguchi R. Hozo: an

environment for building/using ontologies based on a fundamental

consideration of role and relationship. Proceedings of the 13’th

international conference on knowledge engineering and knowledge

management, EKAW02.

[29] Hay DC. Data model patterns: conventions of thought. New York:

Dorset House; 1996.

[30] West M. Information modelling: an analysis of the uses and meanings

of associations, Proceedings of PDT Europe; 2002.

[31] Integration definition for functional modeling (IDEF0), NIST draft

FIPS publication 183; December 1993.

[32] Bazari Z, Redosavijevic D. Product classification and breakdown

structure versus data modelling: a ship mechanical system’s

perspective. Proceedings of European PDT Days 1998 BRE Watford,

UK 1998 pp. 123–132.

[33] Kitamura Y, Sano T, Namba K, Mizoguchi R. A functional concept

ontology and its application to automatic identification of functional

structures. Adv Eng Inform 2002;16(2):145–63.

[34] de Martino T, Falcidieno B, Habinger S. Design and engineering

process integration through a multiple view intermediate modeller in a

distributed object-oriented system environment. CAD 1998;30(6):

437–52.

[35] Pierra G, Sardet E. et al. Exchange of component data: The Plib (ISO

13584) model. Standard and tools, Proceedings of the CALS Europe

1998 Conference, September 1998, Paris, p. 160–176.

[36] van Renssen A. A Guide to STEPlib: guide for the creation and

maintenance of standard data for process plants, ISO

TC184/SC4/WG3/N424; July 1997.

[37] Kalyanapasupathy LE, Minis I. Group technology code generation

over the Internet.: Department of mechanical engineering and institute

for systems research, University of Maryland; 1997.

[38] Newcomb SR. Preemptive reification, Proceedings of the semantic

Web conference; 2002 June 9–12, Sardinia, Italyi Harocks I, Hendler

J, editors. Lecture Notes in computer science volume 23421/2002,

Heidelberg: Springer-Verlag; 2002, p. 414.

[39] Leal D. EPISTLE and the RDF, http://www.cedarlon.demon.co.uk/

epistle/epistle-rdf-note-2001-07-17.html.

[40] Lenat DB, Guha RV. Building large knowledge based systems.

Wokingham, UK: Addison-Wesley; 1990.

[41] Noy NF, Musen MA, Mejino Jr JL, Ross C. Pushing the envelope:

challenges in a frame-based representation of human anatomy. Data

Knowl Eng 2004;48:335–59.