Engineering with Computers

, Volume 19, Issue 4, pp 271–283

A best practice advice system to support automotive engineering analysis processes


    • Department of Mechanical EngineeringUniversity of Bath
  • Y. Liu
    • Faculty of EngineeringUniversity of Bristol
  • R. Crossland
    • Faculty of EngineeringUniversity of Bristol
  • D. Brown
    • Cedar Ltd
  • D. Leal
    • Cedar Ltd
  • J. Devlukia
    • Land Rover
Original Article

DOI: 10.1007/s00366-003-0267-x

Cite this article as:
McMahon, C.A., Liu, Y., Crossland, R. et al. Engineering with Computers (2004) 19: 271. doi:10.1007/s00366-003-0267-x


Engineering design teams today are often widely distributed, and design authority is shared between collaborating companies. Technology is changing rapidly, and understanding of the most appropriate approach to the application of engineering assessment tools is developing accordingly. There is therefore a need to support coordination and auditing of engineering processes, and to provide best practice advice. This paper describes a computing approach to the provision of best practice advice within a workflow-enabled engineering computing environment. The engineering context is described using a formal information model for automotive engineering analysis processes, embedded in an object database. This same model is used to associate best practice advice documents with the engineering context. The best practice adviser (BPA) system assembles four types of information: general information that is pertinent to a particular activity, irrespective of the context in which it is taking place; context-specific information that is pertinent to the particular circumstance in which an activity is taking place; errors and warnings that may be encountered in the activity, especially when software is being used, and examples of previous application of the activity in related contexts. The BPA is implemented in a three-tier architecture using server pages technology. In the absence of any suitable matching information for a particular context in the BPA database, the BPA Server can execute a “close-match” algorithm which searches the database for information that is provided on contexts that are close to the user’s interest. The paper describes the initial implementation and population of the BPA, and presents some early feedback from prototype trials.


Best practice adviceAdaptive hypermediaEngineering analysisEngineering repository


In recent years a number of developments have radically altered the automotive engineering environment. Increasing international collaboration and the search for economies of scale have led to engineering processes being distributed amongst groups of collaborating companies. Similar pressures have led to design authority increasingly being delegated by original equipment manufacturers (OEMs) to their suppliers. The rising capability of computing equipment has led to the growing use of computational analysis, initially as a supplement to component and vehicle testing, but increasingly considered as a substitute for these activities. All of these factors lead to a greater interest in the modelling and auditing of the engineering processes involved in component design and analysis.

These developments in automotive engineering have led to a growing interest in engineering systems that support distributed collaboration and also support the sharing of knowledge and information related to the engineering processes. Computer-supported collaborative work (CSCW), knowledge based engineering (KBE) and information management are all technologies that have been applied in this respect [1, 2, 3]. Some systems that combine different technologies with the aim of providing general support systems have been reported [4], but little has been identified in the way of specific support for durability design, a key automotive design activity and often on the critical path in vehicle development.

This paper is concerned with an element of such an integrated system. It will describe an information support system to provide context-sensitive guidance and best practice support in automotive durability analysis processes. The system has been developed as part of a larger programme of work to develop a design environment to support distributed, workflow-enabled analysis processes in the automotive industry [5]. In this design environment, the work undertaken by collaborating design analysts is modelled and managed by a workflow system in which analysts are guided through all of the activities that make up an analysis process, and an audit trail is developed for the activities as they are carried out. The information support system, called the Best Practice Adviser (BPA), is referenced by the workflow system via hyperlink to provide detailed guidance on how to carry out each activity in the process. It also provides examples of previous similar design work and gives advice on errors and warnings likely to be encountered in the course of the activities.


The overall integrated design environment is called the INTEREST system (from the INTegrated Environment for durability and REliability design Support Tools consortium [5]). It has been designed to provide a number of complementary tools to assist engineers in performing component structural integrity assessment in a distributed business environment. The toolset comprises:
  • The Workflow Management System (WMS), which schedules and monitors design, analysis and test activities.

  • The Job Description System (JDS), an XML-based application that maintains a description of the engineering and operational context of an activity, and also accumulates information about the analysis process as it progresses. The JDS uses a Job Description File (JDF) to maintain the analysis context and display an activity description to the user. The JDF provides an audit trail for the activities, including instructions passed between team members and interactions during decision-making.

  • The Virtual Repository (VR), an engineering data warehouse that manages information about components, activities and documents, building a database of design case histories. It is “virtual” because it includes references to information and documents at other network locations. A Data Manager is provided for exploring the VR and updating its contents.

  • The Best Practice Adviser, as previously noted, which gives detailed information to assist an engineer carrying out an activity.

  • The Tool Management System (TMS), which allows third-party computer applications to be repeatedly executed via driver interfaces. It combines tool wrapping and tool building capabilities with parametric studies, multi-disciplinary optimisation, Monte-Carlo simulation and Design of Experiments [6].

  • A Fatigue Toolbox combines commercially-available fatigue analysis package(s) with probabilistic analysis software. These elements may be used by engineers guided by the JDS or executed by the TMS.

The overall architecture of the system is shown in Fig. 1. For simplicity, the TMS is omitted from this figure. The WMS, JDS, VR and BPA are designed to operate in a Web-based environment either over an Intranet or the Internet. The tools are closely coupled in that information captured by the JDS can be indexed in the VR and used to obtain context-specific advice through the BPA, providing a knowledge-base of design cases that can grow and evolve with changes in business practice. When starting a new design, the VR can be queried to find previous similar cases.
Fig. 1

Overall INTEREST architecture

The BPA may function either closely integrated with the other elements of the system, or as a semi-stand-alone system, using the VR as a database for documents. The operation in either mode is described in the remainder of this paper, the structure of which is as follows. In the next section the current developments in engineering repositories and in content management systems will be described. The BPA will then be introduced, and its use of the Virtual Repository as a mechanism for storing and retrieving advisory documents will be explained. The computer implementation, and in particular the use of dynamically-assembled web pages will then be described, as will the close-match mechanism for providing advice where there is no exactly-matching context specific advice. The paper will conclude with a discussion of lessons learned from the implementation.


The problem for engineers in accessing reliable, up-to-date information has been well-documented. Salzberg and Watkins [7], in their study of a large automobile manufacturer, found that often the issue for engineers was not that the organisation did not have the information that they needed, but that they did not know what was available, or that they could not access the information in a useful form. Konda et al. [8] observe that the issue of how to organise and access the “shared memory” of an organisation is a major issue for engineering design research and practice. Dieter Frank, Head of Research at BMW, observed “Knowledge is the resource of the 21st century . . . those with advanced knowledge management will also be market leaders” [9]. In automotive engineering, knowledge management is made particularly important by the highly distributed nature and the technical complexity of the domain.

The problem of sharing information in specialist domains such as fatigue and fracture or stress analysis has been rather exacerbated by the move to concurrent engineering in project teams, and by the increasing geographic distribution of the design activity [10]. Whereas in a traditional functional organisation design analysts would be co-located and would share knowledge and information through collective filing systems and through formal and informal working associations, in project-based teams functional specialists are often separated from their peers. Where work is distributed through the supply chain this separation may be much more significant. There is therefore a particular need to provide a mechanism for the sharing of knowledge and information among functional specialists. This need is increased by current pressure on timescales, on the increased use of design analysis and by the desire to improve the auditing of the design process [11].

The pressures described above have been seen in many organisational contexts, and have led to the development of approaches to improve the situation by improving managerial practice or by the provision of support technologies. For example, matrix organisations [12] seek to combine the advantages of functional and project-based organisations, although there are many more recent developments in organisations and processes [13]. Support system developments have included the use of computer-supported collaborative work (CSCW) by engineering teams in order to provide virtual co-location [1, 14], lessons-learned databases to store information about how past problems were addressed [15], message or bulletin boards for posting and responding to questions [16] and hypertext help systems to provide on-line guidance and documentation [17].

Adaptive hypermedia

This paper describes an approach that provides a dynamic hypertext help system for the engineering analyst. The system that will be described is adaptive: the content presented to the user is dynamically assembled from a database according to the context in which the user is working. In so doing, the system addresses problems of knowledge management; in other words it provides context sensitive information based on the competence/experience/background of those using the system. Adaptive hypermedia has been applied in a number of other domains. Brusilovsky [18] suggests that it may be classified into content-level adaptation or link-level adaptation, where the former adapts the content of a page and the latter adapts the links, indexes and maps used to navigate the information. Content-level adaptation adapts the content to different users’ circumstances, whereas link-level adaptation provides navigation support to the users. Simple models of adaptive hypermedia of each type might be to have a hard-coded page of information with conditional text according to content rules or to have hyperlinks presented differently according to the user level. For example, Stern et al. describe an adaptive on-line lecture system in which actions taken by the student using the system are reported to a scripting system, which serves adapted pages according to the student’s circumstances [19]. Schwarz [20] describes a self-organised goal-oriented tutoring environment in which adaptive link annotation and adaptive sequencing are used to allow tutoring to respond to user goals. Geldof and Van de Velde [21] describe an adaptive system in which content presented on an information server for an arts festival is specialised according to the date and the place from which the user is using the server. They describe agents (encapsulating information and services) that compete for the user’s attention, based on how they judge themselves relevant and competent to interact with that user in the user’s context.

More sophisticated adaptation can take place when the hypermedia is based on an underlying process model and on categorised information. For example, Bental et al., in providing a support system for patients with cancer, use a hierarchy of information needs based on Coping Theory and a process model of patients’ information needs [22]. They use relevance matching to prevent complex searching: texts are filtered according to the hierarchical Read medical code system [23].

The BPA uses content-level adaptation, and again uses underlying models describing engineering process and context as a basis for the organisation and delivery of information. The models have been based on the Epistle Core Model developed for the process industry [24], and the Engineering Analysis Core Model [25], being developed within the framework of the ISO STEP standard for engineering data exchange [26]. These two models provide a foundation for a schema structure that can be used in conjunction with class libraries that can model physical objects, their properties and behaviours, the states that they may be in, and the actions and actors that may effect changes in state. Other important features of the models are firstly that they make a clear distinction between the persistent objects in the model (physical objects, people, information entities) and the relationships between them, and secondly that relationships, such as connections or possessions of a properties, may change with time. By adopting such an underlying model the system is able to deal with information search and retrieval in the dynamic context of a workflow process.

Successful use of an information model to support search and retrieval is very dependent on the nature and richness of the modelled relationships among the information entities. The most widely-used relationship is the hierarchical parent-child arrangement of entities, often used in the development of taxonomies and ontologies for different subject domains. Examples from engineering include [27, 28]. The hierarchical arrangement of entities is the general approach used in information portals for the Internet, and in directories like the Open Directory Project [29]. A more flexible arrangement than the hierarchy is the directed acyclic graph (DAG), which allows the definition of more general relationships between entities. A static network of hypertext pages may be modelled by a DAG, and they are used for the representation of Bayesian belief networks [30]. The inheritance frameworks of object structures are normally embedded in hierarchies, as used in the context of engineering fatigue and fracture in [31]. Object structures may also represent more general structures through the use of relationship objects to represent relationships between other objects, and that, combined with DAGs, is the approach taken in this paper.

Overview of the BPA approach

The Best Practice Adviser is built upon the Virtual Repository (VR), which firstly allows the definition of object classes and individuals describing activities, physical objects, materials, fabrication methods, documents, actors (people and organisations), software systems and so on, and secondly allows the definition of relationship objects which describe relationships between the other objects – for example relating a document containing advice on how a particular activity should be approached with the activity object and with objects describing the context for the document. In addition, specialisation relationships are stored separately in the VR, which provides a mechanism for the basic schema framework to be extended by the user in a general way, rather than directly using object database features. So the VR structure consists of a fixed, reasonably shallow framework of schema-defined classes as in the information model, which can be freely extended by further user-supplied class specialisations in developing the DAG structure. These extensions can be made interactively using the Data Manager, facilitating customisation to organisational and application requirements.

When a request is made to the BPA for information on a particular activity and context, the BPA makes requests to the VR for object references to documents matching the activity and context, and then assembles these references either as text or as URLs (Uniform Resource Locators) into a BPA page that is displayed to the user. The request may come from an interactive dialog with the user, or from a URL with embedded context description passed from another application.

The information model

The Virtual Repository is based on an underlying information model intended to serve a number of closely-related purposes, which include:
  1. 1.

    Providing the basis for recording information about activities, in particular engineering analyses, that have been carried out to facilitate the re-use of previous component development work and accumulated analysis experience

  2. 2.

    Providing an engineering audit trail in conjunction with a workflow management system

  3. 3.

    Acting as a neutral form for the integration of existing distributed loading and material databases and to enable high level interoperability between durability analysis applications

  4. 4.

    Providing a source for extracting different views of the repository for different applications


Scope of the model

The information model, based closely on Epistle modelling principles [24], contains the following principal, related sub-schemas:
  • A high level framework distinguishing between classes of things, individual things and the associations between things.

  • A Physical object schema for classes of physical objects and their composition, connection and possession associations. ClassOfPhysicalObject includes classes of: functions, such as rotating parts (shafts for example), powertrain parts (pistons for instance); form, such as solid and thin shell parts; features, such as holes, ribs and threads; material, including fabrication and surface finish types.

  • An Activity schema defining both general types of activity (such as FE analysis) and individual activities (for example a specific analysis that is carried out) and their associations, such as their sequence and composition. The way an activity changes the state of a component and the involvement of things in activities is included. The things here include all the inputs and outputs to the activities in the activity models, including the controls and mechanisms, based on the IDEF0 model. It also includes the component type common to the sequence of activities in a given process.

  • A Property schema describing the properties possessed by PhysicalObjects and states. This includes the different types of properties (scalar, vectors, tensors) and the way properties can be combined and related in a general PropertySpace, as represented in the form of graphs, such as for S-N curves.

  • A State schema for recording the states of a physical object, the association with the activities causing the transitions between states, and the properties possessed by different states.

  • A Document schema describing the content, form, version and location of a document. A number of associations between different documents are also defined, including references, derivations and copies.

  • An Administrative schema containing basic location information for organisations, people and machines, ownership of objects and relationships between people and organisations.

The model also provides support for recording the information about statistical analyses of a batch of components, as opposed to individual components, for use in reliability analyses.

Model elements

All entities in the information model are sub-typed from a top entity named Thing, in accordance with Epistle principles [24]. This is not just an abstraction, as there is some administrative information that is common to every Thing in the model, including identification, description and change management or version control.

The second level of the model contains three subtype entities: class, individual and association. An individual is defined as something that has a unique existence, with a beginning and an end. It doesn’t necessarily have to be something that actually exists; it may be something planned. A class is a set of instances of individual of the same type (for instance, FE analysis for activity). This is the same as the OO correspondence between class and objects, where a class is regarded as a manufacturing blueprint for objects of the class. The relationships between high-level entities for activities are shown in Fig. 2, where the bold lines indicate sub-types and the thin lines indicate entity attributes (“string” being a given attribute type).
Fig. 2

Top level structure for activities

An Association is any relationship between two or more instances of Thing, defining what one Thing has to do with another, such as a connection or composition. In the information model, associations are separate entities, which are sub-typed from the top level entities ClassOfAssociation and Association which relate pairs of Things. The association cardinalities are specified as attributes of ClassOfAssociation, for each direction of the association. These then apply to each Association of the ClassOfAssociation, through the MembershipOfClass.

For example, there is an Individual association DescriptionByDocument, between a Document and a Thing, that indicates that the content of the Document can be read by a person or machine in order to learn something about the Thing. It is this relationship in particular that is used by the BPA to identify documents that relate to particular activities and contexts. The use of these relationships is described in more detail in the section Interface to the VR below.

Examples of model elements

For an example of the way that the information model is used to model elements of an engineering analysis, consider the modelling of an automobile engine connecting rod for finite element analysis prior to fatigue analysis. The particular analysis circumstances are described by references to hierarchically decomposed descriptive object classes stored in the Virtual Repository. Individuals related to these object classes provide best-practice documents or precedent examples for the BPA – documents are related to the component context by the DescriptionByDocument relationship, and precedent analyses will be associated with the ComponentType class.

For example, a particular application example may have the context described by the references shown in Table 1. The reference to features indicates the association between the component type and engineering features that the part has.
Table 1

Contextual description of analysis activity

Descriptive Context

Class Reference


BPAActivityTreeRoot – Engineering Analysis of Component – Analysis Model Generation – Simplify and Approximate Geometry

Component form

ComponentType – Form – Solid parts – Connecting rod

Component function

ComponentType – Function – Powertrain components – Reciprocating parts – Connecting rod


MaterialStructureType – Steel – Alloy steel

Method of manufacture

FabricationType – Forged – Impression die

Surface finish

SurfaceFinishType – As forged


Fillet; Bolted joint; Radii; Bearing shell

User knowledge level

UserLevel – Intermediate

Software used

ClassOfProgram – FEA Tools – I-DEAS/MasterSeries

Overall BPA Structure

The overall INTEREST architecture is shown in Fig. 1. The underlying Virtual Repository is accessed by the BPA to identify relevant BPA pages, and also by the workflow elements of the INTEREST system, in particular the Job Description System. The normal mode of operation of the BPA is by a series of hyperlinks from the JDF that describe the context to the BPA by embedding the contextual description in the URL.

Information provided by the BPA is classified into four categories:
  • General information that is pertinent to a particular activity, irrespective of the context in which it is taking place.

  • Context-specific information that is pertinent to the particular circumstance in which an activity is taking place. This is sub-divided into part-specific BPA, which gives information general to the class of components, and feature-specific BPA, which gives information specific to the features possessed by the part.

  • Errors and warnings that may be encountered in the activity, especially when software is being used.

  • Examples of previous application of the activity in related contexts.

The BPA Server will always search the Virtual Repository for information that is an exact match to the context that has been provided. In the absence of any matching information, the BPA Server can execute a close-match algorithm with which it searches the Repository for information that is provided about contexts that are close to the user’s interest.

Implementation of the BPA

The BPA has been written using the “server pages” approach, which allows pure HTML content to be built dynamically according to the user’s input and context. There are a number of server pages technologies that could have been chosen for the task. The BPA has been implemented using the proprietary ColdFusion system, based on available technologies and the target computing environment at the time of initial system implementation [32].

Interface to the VR

The INTEREST schema is designed to support the four basic types of best-practice information noted above. The classification requirements are supported by several types of association incorporated into the schema and the VR, mainly through the document and activity schemas as described below, and shown in Fig. 3.
Fig. 3

Elements of the VR schema relating to the BPA

General Best Practice (BP) comprises information that is irrespective of component, analysis approach or software to be used. It is related to the activity step, corresponding to the ClassOfActivity entity in Fig. 3. The association between the BP document and the ClassOfActivity is recorded using the association BestPracticeAdviceForClassOfActivity which links ClassOfActivity with document. For general BP information, sub-types are defined using a definition which BestPracticeAdviceForClassOfActivity inherits from Class – it can be assigned a value of “topic description” for a brief introduction to the topic incorporated into the top of the BP page, “term” for basic terms which provide explanations of terminology related to this activity or “ordinary” for other general best practice.

Context-specific BP comprises information and links that are specific to a particular context – for example the class of component (solid or sheet metal), the type of its function, or the particular type of analysis or tool to be used. Context-specific BP therefore has to be associated with the context description as well as the activity. In Fig. 3 this information is recorded in the DescriptionByDocument association which can be interrogated bi-directionally in order to find the following information:
  • given a document, what component-types, if any, it relates to

  • given a component-type, what documents, if any, are available

Since the link is made to Thing at the top level of the model, it applies generally to ClassOfPhysicalObject. It therefore applies to features, functions, material-types, surface conditions, and so on. For example, we may want to record advice for specific features, such as ribs, slots, and gear teeth.

The Example BP section comprises particular examples and/or links to examples that are specific to particular instances of activity. The idea here is to provide specific examples, from activities previously carried out, to illustrate some general advice that has been provided at the General and Context-specific level. Documents are related to the activity via the association BestPracticeForActivity, and are also related to individual instances of designs within a given context (for example the design of a component for a particular model of vehicle). This relationship is illustrated in Fig. 4.
Fig. 4

Association between the examples and activity

The Error and Warnings section comprises information and links to the warnings, errors, and troubleshooting measures that apply to the particular activity, and are specific to a particular software system.

The communication strategy between the VR and the BPA

Java RMI [33] has been used as the communication protocol between the VR and the other INTEREST components. In this application, the BPA is the Java RMI client and the VR is the Java RMI server. The VR server exports interfaces for interaction with clients, and provides implementations for the methods defined in these interfaces. This server in turn interrogates the Java Persistent Object Manager (POM) to retrieve various objects from the POM, and returns them to the calling client. The POM is built upon a commercial object database system, POET, which generates the data dictionary, and stores INTEREST objects according to the INTEREST Schema.

Each model class has a corresponding business object class, which in turn has an interface wrapping it to define the remote interface of the VR server. Fig. 5 illustrates the inheritance hierarchy for the interfaces of the INTEREST business object classes. Basically the Object Factory pattern is adopted when designing these interfaces. It has been designed such that only the ISInformationModelServer interface is exported by the VR server. It is unique amongst the business object classes, and does not correspond to a class defined in the INTEREST schema. However, it provides access to all of the other business object classes, and also provides facilities for creating new instances of business objects.
Fig. 5

The inheritance hierarchy of the INTEREST business objects

The interaction between the BPA and the VR also uses this approach. The BPA first calls the getNamedObject method of the ISInformationModelServer interface to create the ISClassOfActivity object, from which methods getGeneralBPADocuments, getExampleBPADocuments, and getContextSpecificBPADocuments are invoked to get different types of BPA information. The execution of these methods returns an ArrayList of BPAInformation objects, which bundles document titles, URLs, and so on together. In this way the network traffic can be reduced, because the document titles and URLs are retrieved on the server side.

Design of the BPA client for the VR

The BPA client has been developed using the Java API of ColdFusion (CFX_J). Custom tags (also known as Java CFXs) retrieve BPA information from the VR, and build the results to the response object into the ColdFusion template file, so that they can be output to the normal HTML file by ColdFusion’s standard output tag <CFOUTPUT>. For each type of BPA information, a custom tag is created. Therefore, there is one custom tag called BPAGeneral for general BPA information, one called BPAContextSpecific for the context-specific information and so on. In addition, several other custom tags are designed to allow the BPA to conduct close-matching operations.

Processing requests

Implementing a Java CFX requires interaction with the Request and Response objects passed to the processRequest method. Every time the custom tag is invoked, the processRequest method will be executed once.

The Request object provides a range of methods for retrieving attributes passed to the tag, including queries, and reading global tag settings. The attributeExists method checks if the attribute was passed to this tag. The getAttribute method retrieves the value of the passed attribute. The getAttributeList method retrieves a list of all attributes passed to the tag.

The Response object is also passed to the processRequest method of the custom tag interface. It provides the method for writing output, generating queries, and setting variables within the calling page. The addQuery method adds a query to the calling page, and the write method can output text into the calling page.

The Query object provides an interface for working with queries, including methods for retrieving name, new count, and column names, as well as methods for getting and setting data elements. The addRows method adds a new row to the query, while the setData method sets a data element within the query.

Figure 6 illustrates the programme flow for implementing the processRequest method.
Fig. 6

The procedure for applying the custom tags

Each Java CFX class has its own associated ClassLoader which loads it and any dependent classes also located in the classes directory. When Java CFXs are reloaded after a change, a new ClassLoader is associated with the freshly loaded class.

BPA client design considerations

The design of the BPA client has exploited an object-oriented approach. First of all a base class is designed as “BPA”. All of the BPA custom tags are sub-classes of this base class. In this base class, a class data member BPA_AGENT is defined, so that all of the sub-classes and their instances can share this common data member. It is of type ISInformationModelServer, and is initialised by using the static method. In addition, object orientation has been used to deal with other common issues in the design of the BPA custom tags. For instance, there are two common utility methods: hasBPADocuments and isFeasible. Both methods are used by all of the BPA close matching algorithms; the former is used to tell whether the given context has BP documents associated with it, whereas the latter checks if the similarity value is equal to or greater than a matching threshold set by users for limiting the document set. In light of these features, a higher-level class BPACloseMatcher is designed to accommodate these common functionalities. All of the BPA close matching algorithms are designed as subclasses of the BPACloseMatcher, so that they can share the above mentioned common methods (close match algorithms will be described in more detail in the section Close match algorithms).

Design of information retrieval tags

The basic method of populating a BPA page with general BP information, using the BPAGeneral tag, is inherited from the superclass BPAWithDefinition. Basically this method loops through a list of information objects passed to it, retrieves relevant information, and builds it into the HTTP response object. When looping through this list, the Java Iterator interface is employed. In Java terms, ArrayList only contains elements of the type Object. Therefore these elements are cast to BPAInformation objects before the data members can be read out. For BPA documents, three items, incorporated as data items of the BPAInformation object, are required to populate the response object, namely: the title of the BPA document; its URL; and the data member definition of BestPracticeForClassOfActivity, which is used to distinguish whether the BPA document(s) comprise topic description, basic terms or ordinary BPA general advice. The process flow for retrieving the general BPA documents is illustrated in Fig. 6.

The design of the BPAContextSpecific tag also follows the basic programme flow outlined in Fig. 6. In this case, however, whereas BPAGeneral only asks for the name of activity, for the retrieval of context specific BPA documents, additional contextual information is required, including component type and function type. Information such as material type, surface finish type, and fabrication type are optional. These types of information are used to build context objects such as ISComponentType, ISClassOfFunction, ISFabricationType, ISMaterialStructureType, and ISSurfaceFinishType. Like the creation of ISClassOfActivity object, these objects are also created by calling the getNamedObject method defined in the ISInformationModelServer interface. In addition, an explicit casting is also required to cast the returned objects to corresponding types, because the getNamedObject method only returns the objects of ISThing type.

Secondly, the method getContextSpecificBPADocuments in the ISClassOfActivity interface is used. According to its definition, the input parameter is of ArrayList type. Therefore, before invoking the getContextSpecificBPADocuments method, the context input should be created by adding each of the context objects mentioned above into an ArrayList.

The execution of getContextSpecificBPADocuments will return an ArrayList containing elements of Java Object type, so it has to be cast into a BPAInformation object first. Then the common utility method populate, inherited from its super class BPANormal, is invoked by adding the results into the response object “file”. The results also include the titles of the returned BPA documents and their URLs. Unlike the BPAGeneral, it doesn’t require the data member definition of the BestPracticeForClassOfActivity.

A similar approach is applied to the retrieval of BPA relating to features using the BPAFeature tag, examples using the BPAExample tag, and error cases using the BPAError tag. They each follow the same programme flow outlined in Fig. 6.

Example BPA population

The initial implementation of the INTEREST information model comprises about 50 activity classes corresponding to tasks carried out during a durability analysis process, and, for testing purposes, a similar small number of classes of form, function, material, fabrication (manufacturing process) and surface finish type. Each set of classes is defined in a user-defined hierarchy extending the relevant schema-defined inheritance hierarchy, as shown in Fig. 5. For test purposes, a maximum of three or four user-defined specification levels have been used in each case, as in the example in Table 1. For example, under Function, the user may define specialisation levels for Powertrain Components, Rotating Parts and Conrods. 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, a topic description has been provided and one or more pages of general BPA have been indexed. The pages can be indexed interactively in the Data Manager using either a form-based interface or using a graphical interface by creating links to the corresponding content descriptors. Alternatively, this information can be imported from page descriptions in an XML file, which may have been recorded in a JDF created during a process execution. In the latter case, the context is created at the start of a process instance, and in some cases certain characteristics may be changed during the component development process, such as changes to the feature set. The current context and user level are recorded in the JDF and, where appropriate, the software application being used. This information is subsequently used to create the page description links within the VR for future access via the BPA.

Context specific information has been provided for some high-level part classes (such as Solid Parts, Power Train Components: Rotating Parts: Rotating Shafts or Metal Cast parts) and for a number of demonstration parts (including crankshafts, connecting rods, steering knuckles). BPA relating to a number of features (for example bolted joints, spot-welds, riveted joints, fillets, oil holes) is given for those activities for which the features are important. The initial population of examples and software errors and warnings is very sparse. Those which have been included have been incorporated principally for test purposes.

Figure 7 shows the screen for the interactive BPA test prototype, with which a user may select a context using drop-down tree controls for each of the contextual attributes (activity, component, material, and so on). When the context has been entered, BPA will be returned when the “Get BPA” link is selected. The user is required to select an Activity plus any number of other contextual attributes. The BPA will always return the maximum information it can for the given context.
Fig. 7

BPA entry screen for selecting component type

For the typical Component Development Process that has been used for fatigue studies in INTEREST, the breakdown into 50 activity classes with three 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 supplying a different activity class library, and it is thought that the same level of detail would generally be suitable for manageable operation, though there is no system constraint on the scope or detail of the class libraries (see the section called Generality of the system).

In contrast to the activity set, in industrial applications a larger class set will commonly be used for some of the component characteristics defining the context. For example, a typical automobile 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.

Close match algorithms

There are potentially a large number of pieces of context-specific information that may be associated with combinations of contextual classes in the VR, even when theoretically possible but unlikely combinations of component, material and fabrication method are omitted. It is therefore likely that, particularly during the early population of the information system, the VR when queried will not return entities that exactly match the context provided by the user. In this case, the BPA uses a close-match search algorithm to search for information in the VR that, although not an exact match to the context, may be of some use to the user. Experiments are being done with a number of close-match algorithms, and these will be reported in another paper, but most experience to date has been with the “up-and-across-the-hierarchy algorithm” which returns to the user context-specific advice associated with the parent or ancestor classes to the current class, or to its siblings. The BPA traverses the links in the hierarchy, and assigns a matching rank according to the number of links traversed. These pages are displayed to the user along with the ranking. Figure 8 shows the user display for an example where the close-match algorithm has been invoked. In this case the BPA given is for a sibling to the current context: the context is Rotating shafts: Camshaft, and the information is recorded for Rotating shafts and its children (such as splined shaft and crankshaft) for which there are geometric similarities. Information is also given for the material and manufacturing process context. Current experimentation is comparing the close-match algorithm performance with expert engineering opinion for a number of application contexts.
Fig. 8

Output from close-match search algorithm


The system as described is currently subject to trials at the industrial partners of the INTEREST system. These trials, and other experimental work, are raising a number of evaluation issues that are discussed below.

The initial trials show a satisfactory system performance, in particular for the distributed architecture chosen. Maximum response time in returning best practice pages, even with the use of the close-match algorithms and using remote access to an NT server on a low-speed connection, is a few seconds. The poorest interactive performance is in the initial build and display of the context selection tree controls in the interactive test harness shown in Fig. 7. Improvement of the interactive performance in this respect has been achieved by caching the object structures.

The information model

The information model is largely adequate for describing the context, but experiments suggest that it may usefully be extended in two respects: firstly, with additional detail on the loading mode (for instance uniaxial, multiaxial, in-phase, and so on) since the capabilities of fatigue algorithms vary greatly with loading. The initial schema contains a ClassOfLoading, as a sub-type of ClassOfActivity. From the modelling viewpoint, the argument is that loading is itself an activity that may be simulated by analyses. But from the user viewpoint, it would be better to have it as a separate top-level entity so that it becomes immediately visible. The different loading characteristics (mode, phase etc) could be added to the schema as top-level sub-classes. Secondly, it has been proposed that the information model should be extended to allow decisions taken during a process that impinge on the advice given at later activities in the process to be recorded. At present the advice given has to reflect all of the possible decisions that might have been taken earlier in the process. By recording the decisions in the information model more specialised advice could be given.

System population

As discussed in the Example BPA population section, in these trial evaluations the class libraries have been tailored for use with fatigue analysis. Whilst the extent of the activity class set is considered typical for use with other processes, for some other applications larger physical object class libraries would be expected (for example a larger set of component functions). In such cases the close match algorithms become even more important. At present, the search traversals for these algorithms are confined to the physical object class hierarchies and do not apply to the activity class hierarchy, so if an activity breakdown is used, systematic Best Practice population at the different task and sub-task levels should be employed.

Close match algorithms

The close match algorithms are subject to particular attention in current testing, and it would be premature to make any extensive commentary here. Some initial observations may however be made. Firstly, in general, in a broad, neutral information system, close match searches should depend on the viewpoint of the user; in other words different users will attach different importance to different classifications and component properties. In INTEREST, the durability analysis viewpoint predominates, so the close match algorithms are biased towards the functional classification. Therefore the algorithms first search the function hierarchy, and then look for siblings in this hierarchy. This also applies to the feature-based algorithms. For some activities this is not so appropriate: for example in advising on how to improve a part that has poor fatigue performance the material and method of manufacture are very important. This suggests that the close-match algorithm and target contextual description should be varied depending on the activity.

In the test implementation, the use of close-match algorithms is offered to the user if no exact match information may be found. Initial testing suggests that it would be appropriate to make close-match searching the default mode, and to exploit the algorithm by putting information in the most generic category.

Interactive use

Although predominantly designed for use in conjunction with a workflow/job description system, interactive use of the BPA through the test harness has proved popular. This interactive use has been made more straightforward by the incorporation into the test harness of a “Common Component” menu (see Fig. 9), which allows all of the contextual attributes for a number of standard automotive parts to be selected with a single selection. The method of passing parameters to the BPA also allows simple HTML pages to be produced describing the process of carrying out an analysis for a particular component, with the context described in embedded links to the BPA for each activity.
Fig. 9

Selection of common components

Industrial application

Use within a knowledge management framework

As noted in the Background section, knowledge management (KM) is now widely regarded as an important business issue, not least by those in automotive engineering. This paper has described how the BPA can be used as a tool to assist knowledge retrieval and sharing in a collaborative design analysis environment. A number of KM pioneers have stressed that initiatives involving the introduction of such KM tools and systems should be considered from a general business perspective within a KM framework, rather than from just a technical viewpoint [34]. Such arguments apply generally to the introduction of new IT tools, but are more important for the effective application of KM tools. This is mainly due to the need to align application of the tools with the prevailing organisational culture and strategy and with the business processes, especially where collaborative working and knowledge sharing are concerned. In the case of the BPA, there is a natural fit with business processes due to the system architecture.

There is some evidence that, as one might expect, the “collaborative climate” of an organisation has an influence on the effectiveness of knowledge work [35]. This has also been borne out in industrial practice by knowledge sharing between manufacturers and their component suppliers, as in the use of lean supply chains pioneered by Japanese manufacturers, see [36].

Another important consideration for knowledge sharing is the organisation’s strategy concerning codification of implicit knowledge – explicitly recording knowledge using tools like the BPA. This is sometimes referred to as externalisation in the business management literature, a term introduced by Nonaka and Takeuchi [37]. They actually refer to the externalisation of tacit knowledge, which includes attempts to produce procedural representations of manual skills, though there is still epistemological debate as to the nature of tacit knowledge and whether it can be codified. Whilst externalisation provides a range of benefits, it can be time consuming and costly and may pose some additional security risks, as codified knowledge naturally tends to be more leaky. Hence the extent of externalisation is an important strategic management decision for KM initiatives.

Business benefits

As touched upon in the introductory sections of this paper, the use of KM tools like the BPA offer the prospect of a range of business benefits including:
  • Productivity improvements by making relevant knowledge more readily accessible and therefore reducing search times

  • Reduction in costs by avoiding repeatedly solving the same problem and avoiding previous mistakes

  • Facilitating organisational learning, with knowledge diffusing to less experienced staff

  • Reduction in redundancy of knowledge-based activities through knowledge sharing. This can be particularly significant if sharing occurs across conventional business and engineering units

  • Improvement in retention of knowledge when “knowledge workers” leave an organisation

  • Improvement in organisational responsiveness, technical decisions about product development, and speed of innovation, as a consequence of the above

  • Greater employee satisfaction through improved personal development and empowerment

Despite these attractions, because KMS are introduced in dynamic business environments, producing a direct correlation between a KMS initiative and specific business results is difficult to achieve. A further difficulty is distinguishing benefits derived directly from use of tools like the BPA, since, as described above, these should ideally be introduced as part of a wider KM initiative which may involve changes in working practices. It is also difficult to assess the benefits attributable directly to use of the system itself, as opposed to its contents, the worth and lifetime of which may vary according to the application of the tool. Therefore, generally one can only attempt to measure the impact of such initiatives as a whole.

During the last few years a number of surveys have been conducted, as summarised in [38], which have generally provided supporting evidence for the benefits listed above, though actual ROI calculations are still quite rare. Nevertheless, there are now a number of success stories where such calculations have been published, such as in case studies on the APQC website [39] and in the business management press. In some cases this has resulted in significant cost savings, especially for some pioneering KM applications in the petrochemical industry. To date, the BPA has only been evaluated as an R&D pilot development, so no attempts at estimating savings have been made. Clearly this will be largely dependent on the actual business application and subject to the provisos outlined above.

Generality of the system

The final – and perhaps most important – observation is that, although designed to support engineering analysis, the BPA can in principle provide best practice support to any process that may be described as a series of activities, and for which the context in which the activities are carried out may be described by hierarchically decomposed categorisations. The BPA/VR combination is therefore a very generic system with appropriate modification of the PhysicalObject schema as necessary and population with appropriate class libraries for the domain. For other engineering and scientific contexts, the schema can be almost directly applied with appropriate renaming of some schema classes as needed, and substitution of appropriate class libraries. For example, in applications such as medicine, anatomy and molecular modelling, the division into Form, Function, Material and Feature and so on can be directly applied. For other business contexts, some modifications to the schema may be necessary according to the domain, but nevertheless they should be straightforward to carry out. We believe that in this way a combination of automated best practice support and workflow-enabled processes will become widespread in engineering and in other disciplines over the next few years.


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.

Copyright information

© Springer-Verlag London Limited 2004