STEP AP233 + Standard PDM = Systems Engineering PDM? [original]

STEP AP233 + Standard PDM = Systems

Engineering PDM ?

Roland Eckert1, Wolfgang Mansel2, Günther Specht3

1EADS Deutschland GmbH, 81663 Munich, Germany, [email protected]

2EADS Deutschland GmbH, 81663 Munich, Germany, [email protected]m

3University of Ulm,, 89069 Ulm, Germany, specht@informatik.uni-ulm.de

Abstract

In the manufacturing industry Product Data Management (PDM) systems are backbone systems. As such they have

to support the collaborative creation, management, dissemination, and use of product definition information across

the extended enterprise from concept to end of life – integrating people, processes, business systems, and

information. A drawback is that today’s PDM systems are focussed on mechanical engineering. There is however an

increasing need, for instance from aerospace industry, for an extended PDM system, which covers systems

engineering product aspects.

For storing information in a PDM system a data base schema is necessary. Most of PDM systems base on something

like the “PDMschema”. It is only restricted suitable for a systems engineering environment. STEP ISO 10303 -

AP233 provides an appropriate approach for integrating systems engineering needs into PDM systems, specifically

future modularised STEP ISO 10303 application protocols will make it possible to construct the required PDM

schema extensions at reduced customisation effort. A framework for a systems engineering PDM system is proposed

and data exchange aspects discussed. A demonstrator for the proposed solution was build using AP233 gateways for

systems engineering CASE tools coupled to an appropriate PDM system.

Keywords:

PDM, STEP, AP223, System Engineering, Data Exchange

1 Introduction

In the manufacturing industry, Product Data Management (PDM) Systems are widely accepted

and established as an integration platform for full product life cycle information, i.e., embracing

information associated with project phases from concept to disposal. A variety of tool providers

offer PDM solutions, but there exists no generally accepted definition what a PDM system is.

We were faced with the fact, that the customisation of a PDM System is a big cost driver.

The first cost driver is that out-of-the-box available PDM systems do not offer domain specific

functionality. Today’s PDM systems are limited to support structural design and management of

bill of material, while support to systems engineering and coupling to Computer Aided System

Engineering (CASE) tools are missing.

A second cost driver is that in industrial collaborative projects every partner has evolved and

customized his own PDM data model. In most cases there is a difference in the understanding of

which information is to be exchanged amongst the partners and so in most cases no agreement is

available on which information has to be stored in the PDM system. Consequently it is possible

to have inconsistent and redundant functionality definition or even different semantics in the data

models of the PDM systems. For example the data models support different names for the same

data item, or the same names for different data items. Because of different levels of detail,

divergent semantics and confusion in naming conventions, data exchange becomes complicated

and it is very difficult and expensive to share information.

11th Int. Conf. on Concurrent Enterprising (ICE 2005),

20.-22. June 2005, Munich, CCE (Press), Nottingham, UK, pp. 405-412

A third cost driver is that if companies start to work with a PDM system as a backbone system

they have to develop migration strategies and they have to standardize their data (Carlyle, 1990).

It is necessary to have standards e.g. for naming conventions. That however can only be solved

by the discipline of the user and it is not possible to solve that by the semantic of the data model.

The first cost driver was addressed by the European Commission funded SEDRES project

(SEDRES2 IST-1999-11953 and SEDRES ESPRIT 20496 1996), where the European aircraft

industries initiated the development of a domain specific STEP ISO 10303 Application Protocol

AP233 (AP233) for Systems Engineering data representation and exchange. The development

resulted in Publicly Available Specification PAS 20542, a precursor to the on-going

development of Modular AP233. From this basis, we have investigated if AP233 is suitable for a

federative extension of the PDM data model and for data exchange between PDM systems to

address the second cost driver, which is discussed within this paper.

2 Industrial Needs of Manufacturing Industry

Industry needs an environment to facilitate collaboration and concurrent development in large

systems engineering project, e.g. multi-company aircraft development, that requires the sharing

of systems engineering information between relevant stakeholders, regardless of the (current)

barriers arising from the lack of open semantic standards and lack of interoperability of tools and

PDM environments (Eckert, 2003). Industry is confronted with the fact that products are

becoming more complex. In performing the systems engineering task, an increased number of

systems engineering tools is involved. It is necessary to have a simple way of exchanging

information between collaborative partners, avoiding the problems of expensive data conversion

processes, duplicate data creation and redundant data management. It should be born in mind that

60% of engineers’ time is spent in the search for relevant information (Langenberg, 2000).

Customisation of PDM systems should not be the task of manufacturing industries. It should be

possible to assemble a suitable environment with CASE design tools and PDM system out of

standardised modules, with ongoing tool updates being provided by the tool supplier. By

performing standardisation it can be guaranteed that the ‘out-of-the-box’ data model modules

fulfil accepted quality guidlines. (Reingruber, 1994) defines a quality product by its correctness,

its suitability for use, its adherence to a predetermined set of expectations, or its freedom from

mistakes or flaws.

2.1 State of the Art – Solution for Data Exchange

Most of the literature describes either PDM Systems that are used in the automotive industry

(e.g. Schoettner, 1999; Scheder, 1997) or generic PDM Systems (Atkinson, 1998). The described

PDM Systems, (e.g. aeronautic sector) are limited to geometric structure management, document

management, product management and configuration management (Karcher, 2002). The reality

is that whereas most engineers in manufacturing industry have substantive needs that are not

fulfilled by a PDM System, only a fraction of the functionality potentially provided by the PDM

System is used in most companies (Gustavsson, 1994; Alenius, 1994).

2.2 STEP PDMSchema V1.2

The PDMSchema (Buchanan, 2002) is an initiative of PDES Inc. together with the European car

industry, and is not standardised by the ISO. It is covers the ISO 10303 Application Protocols AP

214 (core data for automotive design process), AP 212 (electro-technical design and installation),

AP 203 (configuration controlled design) and AP 232 (technical data packaging) (PDM-IF,

2003), and builds on a common understanding of product data among trading partners with the

objective of providing a mechanism that is capable of describing product data throughout the life

cycle of a product, independent of any particular system.

At present, major activities of the joint industry and government initiative "Product Life Cycle

Support (PLCS)" are underway to develop a new standard, AP239. AP239 addresses a perceived

gap in the scope of existing standards by providing for the management of assured product and

support information throughout the entire product life cycle from concept to disposal. It also

exploits the lessons learned by the process industry (http//www.epistle.ws) in developing a life-

cycle approach data management for their domain (ISO 15926). Due to significant overlaps with

Systems Engineering aspects, the AP233 concepts of function, functional (ISO 10303-1216) and

system breakdown structure (ISO 10303-1214) were standardised by the PLCS Project as joint

AP233/AP239 modules.

2.3 STEP AP233

AP233 is an application protocol under ISO/STEP/SC4 that is creating an information model to

capture the semantics of systems engineering as a basis for the interchange of information among

tools. The AP233 activities are the basis for rigorous requirements that are computer

interpretable, shared among different tools, and available over the Internet. AP233 will provide

the basis for global sourcing of both products and services, covering the full life cycle,

throughout the supplier chain, and across the boundaries of disparate organization cultures,

processes, training, and tools. Baseline for AP233 is the process definition in EIA/IS-632.

The AP233 data model supports the following concepts:

• System and subsystem views including hierarchies

• Requirements: text and model-based + requirements traceability

• System behaviour and functional architecture

• Functional decomposition, interfaces, & allocation

• Functional & data flows; behaviour models; finite state machines

• System physical architecture and interface control

• Component decomposition, interfaces, & allocation

• Parts libraries & product lines

• System properties, classification and data definition

• System engineering data management

• Model layout and presentation information

AP233 is currently being developed further (Eckert, 2005) toward a modular standardised

application protocol, which additionally supports concepts embraced in areas such as:

• User-defined attributes

• Document order

• Work breakdown

• Binary representation items

• Textual expression representation

• Security & information rights

• Product as released

• Risk analysis,…

2.4 Modularised STEP Application Protocols

STEP ISO 10303 is now moving to modularised application protocols (Anderl, 2000; ISO,

2001), providing the advantage of better harmonisation and thus interoperability between the

APs by re-using already existing modules and making it possible to develop application quicker.

There are also potential benefits from re-using not only the data model of the module, but also

interface software components associated with the module, and even test and qualification data.

In the future new APs could be constructed with a toolbox supporting a choice of appropriate

modules. Thus, the modularised AP can reduce the high cost of developing a domain-specific

application protocol.

The modules are protected by the ISO: by using such standards it is much easier to define a

common data dictionary that defines the common semantic of the project, e.g. divergent tool

semantics , e.g.Project – Product -Variant or Issue – Version - Revision et cetera.

Modularised application protocols will also be beneficial for PDM systems, especially when

AP233 is integrated. With a customized data model, incompatibilities with AP233 interfaces and

updated versions of the PDM tool are highly probable. If the PDMSchema is extended by

publicly-available modules, the maintenance of compatibility it is more realistic. In summary, we

can say that the modularised ISO standard will archive interoperability of system design

environments with PDM environments.

3 A Framework for Extension of established PDM

3.1 Example of a Systems Engineering PDM System

The systems engineering discipline structures a product into the requirements, which are the

baseline for product development, the system functions, which implement the requirements, and

the system architecture providing the network of components to which the functions are

allocated. Design description elements detail requirements, functions and components and need

to be linked to the systems engineering product structure elements defined above. Systems

engineering CASE tools are capable of handling such structures to support the design process,

although, however, they do not provide product management capabilities e.g. integrated change

management.

As explained in Sec. 2.3, AP233 supports such structures, but does not cover the PDM aspects.

The PDMSchema however, provides product management capabilities only for the physical

product, which is in essence the bill of materials. To satisfy systems engineering needs it is

reasonable to extend the PDMSchema to provide an extended product view, as shown in Figure

3.1 for an aircraft application.

Part List

Physical Product

Struktur

The Physical Product

System Breakdown Hierarchy

Hydraulic SystemHydraulic System

Avionic SystemAvionic System Fuel SystemFuel System

ECSECS

FCSFCS

Avionic & Ar ma ment

Ver.

16.0 3. 9

Basic Navi

ation

NAV Moding

NAV Calculations

Monitors

Displays

Navi

ation Fi xin

Height Sensor Logic

Unplanned Fixing

Planned Fi xing

Displays

Navigation Steering

Displays

Steering Calculations

ASB Steering

HSI Ste ering

Track Steering

HMCF

MLS

Time Early Late

ir to Air Sidewinder

Gun

Air to Ground

Basic Weapon

Stand Off

Stanoff Delivery

Reversionary Standoff

MCS Operation

APACHE

External

VHF/UHF

E:UHF

ODI N

IFF

TACA N

Internal

Navigation

Wea

on Aimin

Electronic Warfare

Communications

Functional Tree

Implemented by Onboard

Computing System

Aircraft System Functions

Airframe

Aircraft Infrastructure

ure 3.1: Total Product View

To integrate systems engineering into a total product data management it is therefore reasonable

to extend the PDM product structure schema to include:

• Functional Product Structure (FPS)

• System Product Structure (SPS)

• Physical Product Structure (PPS)

• Requirement Structure Tree (RST).

The requirements structure tree allows interlinkages to other product structures which contain the

elements which implement the requirements. This traceability will allow an impact analyse of

new or changing requirements on product development. The functional product structure

includes all system functions and provides the basis for functional system qualification. The

System Product Structure is the system/subsystem breakdown hierarchy from a component

viewpoint. It is defined e.g. in AECM 1000D (AECMA, 1999) which is used for customer

product support of avionic systems. The physical product structure exists within the framework

of structural design and applies to the part structure which is used for the management of

geometric and physical product information (3-D geometry data, bill of materials, etc.) The

structure is manufacturing- and assembly-oriented and is typically known from AP214 and

PDM. Every construction is represented only once in the structure, but carries a quantity.

A demand specific application protocol could be built up by reusing the corresponding parts

from AP233 and combining it with the PDMSchema. This would result in a solution as shown in

Figure 3.2.

PDM EADS - M

CASE Tool A

CASE Tool B

AP 233

Modules

Requirements

FPS

Functional Product Structure

SPS

System Product Structure

PPS

Physical Product Structure

P 21 / XML

PDM

Schema

P21 / XML

PDM

Suppliers,

Customers,

Programme Partners

PDM

CAx Tool A

CAx Tool B

Figure 3.2: Structure of a PDM system in the System Engineering Domain

All product structures in the Systems Engineering PDM described above are related and have the

same generic assembly as their basis. With the same basis it is possible to use the same

affectivities and the same access rights for all structures.

The design information related to the RST, FPS, SPS and PPS is originally distributed over

different CASE Tools, on different systems. The advantage of a PDM system as proposed by

Figure 3.2 is to have an integrated product and project data model containing all product and

project documentation independent of the system on which it was created, thus enabling total

product management.

The PDM system enables the faster and earlier release of information and the reuse of the stored

data. The branches of the trees determines the order in which parts will be collected together and

the node indicates how and when parts are to be linked or merged together.

3.2 Extended PDM Data Exchange

Data Exchange enables cooperation between industrial partners in a consortium. It allows the

linking of different PDM systems, thus providing all the latest information about a product to

every partner. By using the PDMSchema, the relevant companies can exchange the product

structure, bill of material and configuration data. In future, the flexible sharing of knowledge

amongst the team and with the suppliers will be a criterion determining the success of

cooperation with external partners, customers and suppliers.

With the PDMSchema extended by AP233 modules, it is possible to import and export relevant

information from different CASE/CAx tools into/from the PDM system. In this way, the a user

will get a tool-neutral holistic view of the system that has to be developed for the first time.

The aim of the PDMSchema is to offer a generic data model for PDM systems. A PDMSchema

extended for systems engineering and constructed from modularised application protocols will

reduce the need to customise PDM tools. This will as a consequence provide less expensive

solutions for data exchange.

3.3 Systems Engineering PDM System Realisation Perspectives

At EADS Military Aircraft, the PDM system Metaphase (now Teamcenter Enterprise / HCL

Technologies Ltd.) was introduced to support the maintenance phase of the Eurofighter aircraft.

During customisation of the standard Metaphase data model, systems engineering aspects were

already considered, in that the PDM product structure schema was extended to cover functional

and system breakdown aspects.

The extended PDMSchema of our Metaphase customisation provide a good baseline for a

feasibility study as to how to integrate design data from systems engineering CASE tools into a

PDM system by using AP233. The focus was the import of the functional product structure from

systems engineering CASE tools into Metaphase. The systems engineering CASE tools

TeamworkTM (Telelogic/Computer Associated), StatemateTM (I-logix) and DOORSTM

(Telelogic) were investigated, all running on separate workstations. The representation of the

functional system hierarchy in all the three tools for an aircraft landing gear control system is

shown in Figure 3.3. The data representation in the tools uses different semantics, but provided

for the exchanged by means of AP233 Interfaces.

Figure 3.3: Representation of Functional System Hierarchy in the CASE Tools Teamwork,

Statemate and DOORS (from left to right)

To integrate the CASE tool data into the Metaphase PDMSchema, the AP233 data model was

mapped onto our customised Metaphase data model by using the PDTec Tool PDMConnect. The

data of the functional hierarchy imported into the PDM system are shown in Figure 3.4.

ure 3.4: Im

orted Functional Product Structure into PDM

With this step it is now possible to establish the relationship of this information with the

requirements, the system product structure, the physical product structure or the documents. The

systems engineers now have the possibility of generating query notes or test reports on the nodes.

All information from the various CASE Tools is now displayed in the same semantics and is

accessible via one single workstation and one single PDM system, and an integrated change

process can be supported.

4 Conclusion

PDMSchema is a generic resource specialised in product management, and is currently not able

to support domain-specific requirements. In future, it will be possible to extend the existing

schema by the required modules from other application protocols. It will thus be possible that

every specific sector can very rapidly and cheaply build up their specific PDM system, built up

out of standardised modules. Incorporating an existing AP module into a system saves the cost of

developing the component, and leads to consequent savings in terms of schedule and

development costs.

The entire software community is well aware that the problems of interoperability are manifold

and are not likely to disappear quickly. AP233, following the pioneering efforts of the SEDRES

contracts, is one more step in the direction of overcoming the difficulties.

SEDRES provides a solid base for Systems Engineering data exchange and interface

implementation. The interfaces and information transfers demonstrated with SEDRES that the

emerging AP233 standard could be an efficient medium for tool- and vendor-independent

transfer of systems engineering information. The modularised AP233 will make the use of PDM

systems for systems engineers considerably more effective. Engineers will be able to access the

information required for design activities much more easily. The objective of the modularised

APs are to achieve practical integration of the data in a PDM system, as required by systems

engineers, regardless of source and throughout the system engineering activities. Without the

modularisation of STEP, the implementation of data exchange systems will be very slow.

Indeed, the lack of interoperability between current APs and hence industry sectors may well

stop many companies from taking advantage of the benefits of electronic exchange of product

model data.

Due to significant overlap with Systems Engineering aspects, the AP233 concepts of functional

(ISO 10303-1216) and system breakdown structure (ISO 10303-1214) were standardised by the

PLCS Project as joint AP233/AP239 modules.

The suggested PDM system links product data to the enterprise workflow by providing a toolbox

for the modelling of product structures and engineering processes. It is the integration of systems

engineering design and analysis tools and product data management environments that remove

the semantic boundaries between these classes of tools. By means of the PDM System, the

CASE tools get access to such PDM features as extended configuration- and change-

management and data exchange.

References

Alenius, L.,et al., PDM systems – a swedish market overview, IVF-skrift 91828, IVF, 1991

Anderl, R., Modularisation and Component Structures Maintenance, Interoperability and Scope Extension of

Application Protocols on a Modular Basis, ProSTEP Science Days, 2000

AP233, ISO/DRAFT-PAS 20542:2004(E), Industrial automation systems and integration - Reference model for

Atkinson, C., Mandemaker, T.H., PDM in a Systems Engineering Environment; European PDT Days, 1998

Buchanan, K. D., Usage Guide for the STEP PDMSchema, Release 4.3, PDM Implementator Forum, 2002

Carlyle, R., Is Your Data Ready for the Repository?, Datamation, 36, 1990, p. 43-47

Eckert, R., Johansson, G., Experiences from the use and development of ISO 10303-233 Interfaces in the

systems Engineering Domain, ICE 2003, 2003, p. 501-508

Eckert, R., Mansel, W., Specht, G., Model Transfer among CASE Tools in Systems Engineering, Systems

Engineering, Wiley Periodicals, Inc., Volume 8, Number 1, 2005, p. 41-50.

Gustafsson, I., Product Data Management Systems in Swedish Manufacturing Companies, Report, Sveriges

Verkstadsindustrier, 1994

ISO, ISO 10303-1, Industrial automation systems and integration — Product data representation and exchange

— Part 1: Overview and fundamental principles, ISO copyright office, Geneva, Switzerland, 1994

Kemmerer, S. (ed.), STEP - The Grand Experience, NIST Special publication 939, 1999

Langenberg, L., Firmenspezifische Wissensportale für die Produktentwicklung, Fakultät für Maschinenbau der

Ruhr-Universität Bochum, 2000

Reingruber, M. C., Gregory, W- W., The Data Modeling Handbook, A best-Practice Approach to Building

Quality Data Models, Wiley-QED, 1994

Scheder, H., Requirements of Car Manufacturers for Product Data Management in an Extended Enterprise,

STEP Forum '97, Munich, ProSTEP GmbH, 1997

Schöttner, J, Produktdatenmanagement in der Fertigungsindustrie, Hanser Verlag, 1999