INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN, ICED’07
28 - 31 AUGUST 2007, CITÉ DES SCIENCES ET DE L'INDUSTRIE, PARIS, FRANCE
FACILITATING INTERDISCIPLINARY PLM THROUGH
USAGE OF HUB METHODOLOGY AND 3D
LIGHTWEIGHT VISUALISATION DATA
Trond Zimmerman1 and Johan Malmqvist2
1Volvo Information Technology AB, Göteborg, Sweden
2Chalmers University of Technology, Göteborg, Sweden
ABSTRACT
Demands on shortened development leadtimes in many branches of the manufacturing industry has implied earlier and more intense efforts of sales, manufacturing and aftermarket preparations than before. Thus, the need of sharing emerging pieces of the product definition from product development to downstream processes such as manufacturing and aftermarket has received more attention in later times. An important view of the product definition is its geometrical representation. Distribution and use of 3D visualisation data is a critical ability for an effective downstream development.
This work relates to a study in the commercial vehicle industry and concern issues on how to efficiently distribute configured visualisation data to the aftermarket preparation process throughout the product development process, including the conceptual design phases. This includes utilisation of visualisation data for production of service and repair methods, service information, parts assortment and spare parts information.
The results unfold information needs from, and requirements on the Product Lifecycle Management (PLM) system, from an aftermarket perspective. These prerequisites are set in relation to available information technology and utilised or evolved architectural concepts. The analysis comprise an exploitation of 3D lightweight formats as a mean for carrying geometrical definitions between processes and organisations, as well as different standards and techniques for establishing a working application and infrastructure architecture in support. The principal element is an architectural design for an Engineering Portal (Hub) and adherent feasibility analysis.
Keywords: Product development, aftermarket, visualisation, multi-CAD, PDM
1 BACKGROUND
Product development of today includes management of large quantities of product-related data that is very often interrelated in a complex way. With the wide-spread use of digital engineering tools, the data managed normally encompasses multiple views of the product, each of them capturing a subset of the final product’s properties. In the commercial vehicle industry, the most common view used is the product’s geometrical representation. It can encompass the visualisation of a single part, a subassembly or the entire product. The latter are sometimes referred to as Digital Mock-Ups (DMU), and baselines out of these as virtual prototypes [1]. In a manufacturing company, the product definition master is normally created and owned by a product development unit. If the product is complex and comprises many parts, a large number of designers are likely to be involved in its creation. But a considerably larger number of engineers throughout the company are to be regarded as potential users of these geometry representations [2]. There is a variety of applications for product geometries to be found in sales, manufacturing and aftermarket businesses, e.g. virtual order configurations, virtual manufacturing, virtual service method development and spare parts planning. In this way, communication of geometry (visualisation) data from product development through the interface towards downstream processes and their users becomes an important PLM performance aspect, see Figure 1.
Product D a ta C o n fi g urat ion and V is u al is ati o n PDM CAD Aftermarket Manufacturing Sales Product Development DMU
Figure 1 Visualisation data interface for downstream processes
A not uncommon challenge is that engineering data is stored at multiple physical and logical locations [3], and that means for consolidating a common view of the product definition are defective. Visualisation data is most frequently stored and made accessible in native formats with respect to Computer Aided Design (CAD) and Product Data Management (PDM) systems. This means that rather expensive and complex CAD systems need to be used to access, understand, and perform the wide variety of analyses and preparations that need to be done in downstream processes to enable the sales, manufacturing and aftermarket development.
Concurrent engineering as a mean to speed up development cycles has been given an increased level of attention in later years. This means that manufacturing and aftermarket engineers actively influence the product design, even at conceptual stages in the development cycle. Furthermore, it requires that manufacturing and aftermarket development is started early, to avoid a sequential process and thus gain time to market with new products. A bottle-neck for boosting collaboration efficiency in this cross-functional work is the ability to access visualisation data early in the process. In addition, to control the product configuration throughout the process, thus being able to track all changes that are performed, becomes very important for tracing downstream preparations to product geometries. This ability certainly affects quality in engineering work throughout the development process.
New PLM technologies and thinking have emerged during later years. Visualisation data formats and tools that operate them have been made available through different software vendors and organisations. The data structures embedded in these formats are reduced to make usage of data easier in typical downstream functions, e.g. aftermarket support development. Some of these formats have also been made available for the public, which in turn have enabled certain levels of data interoperability between different tools. The formats as such are sometimes referred to as 3D lightweight formats. The multiplicities of tools available on the market that operate on these formats have due to competition and relative simplicity to develop new software lead to lowered costs. Furthermore, lightweight formats and related technologies are to be regarded as potential enablers for managing a multi-CAD environment. Interoperability and related conversion services between native CAD data and 3D lightweight data are generally available, and could thus constitute a consolidating engine between different CAD systems, both with respect to product development as well as downstream processes. In conclusion, there are significant benefits in letting downstream processes retrieve and do their work based on data in these formats and tools have been easily glimpsed when scrutinising this technology movement.
2 OBJECTIVES
The prime objectives for the study have been to
1. Identify and describe the needs for an efficient PLM solution with focus on the aftermarket
discipline
2. Map out the essentials of relevant technologies that would help in realising a solution for these
needs
3. Identify a solution concept based on those technologies that would support the aftermarket
business
3 RESEARCH METHOD
The research method deployed in this work has to a large extent relied upon active participation in a research and development project in a large manufacturing company. A series of interviews have been performed to understand and to map out essential business needs and available solution concepts. Workshops with practicing engineers have been carried out to continuously verify the researchers’ ideas in terms of how an IT solution that supports the coordination of upstream and downstream information should be developed. The aftermarket function has been utilised as a representative downstream function in terms of driving the technical issues in a business and research context. In additions to workshops, verification of results is performed through the setup and testing of a software prototype.
Six different scenarios have been utilized to manifest aftermarket needs and requirements.
1. Information retrieval and change notification
2. Feedback to product development, including maintainability analysis and service method
development
3. Authoring of interactive 3D information for service method production
4. 3D simulations for training of workshop mechanics
5. Production of 2D information illustrations and images, which applies to both service
information and spare parts information production
6. Production of high quality illustrations for training and marketing purposes
4 NEEDS AND REQUIREMENTS
4.1 Analysis
The increased demands on shortened development leadtimes in the commercial vehicle industry has necessitated more focus on cross-functional efforts in early phases of product development. Typical aftermarket products that are worked upon, related to, and in parallel with design work, comprise the service and repair method system and the spare parts system. In the conceptual design phases of a product development project, much effort from the aftermarket side regards requirement engineering work, and thus to provide feedback to designers on their concepts. The earlier an aftermarket analysis on strengths and weaknesses of a particular product design could reach its originator, the better prerequisites for reaching a sound solution [4]. In addition, the better chances of cutting time to market as well. One kind of aftermarket feedback that can be provided to product development originates from maintainability analyses on design. It relates to service method development. Another kind of possible feedback originates from availability analyses on the design in conjunction with different variance distribution analyses. It relates to spare parts planning.
In the detailed design phase, much effort is spent in systematically verifying technical solutions and to drive adaptations of the products to aftermarket operations. An easy retrieval and an efficient use of visualisation data during this phase is a mean for sustaining product quality, but also to avoid expensive use of physical prototypes. Development of the aftermarket support system is being initialised here. It is however completed during the industrialisation phase. Aftermarket design items worked upon include repair/service methods, service information, parts assortment and spare parts information.
Technology developments in the visualisation area in recent times do provide new means for delivering an enhanced aftermarket support system in conjunction with the actual products. Traditionally, service and spare parts information have been delivered in 2D on paper format. Also training material for workshop mechanics has been in that format. Improved hardware and software technology today enables this kind of information to be delivered as a virtual product in 3D through an interactive methodology. Producing such systems set new demands on repurposing of visualisation data along the development process.
To secure consistent work on the aftermarket side along the development process some key functional requirements that regard information management have been identified. These are important needs as the product definition is in a constant move all along the process, including product variety aspects as well as change management aspects.
Correctness – The correct information should be available for use at all times. All measures performed
are continuously informed about any changes in their used sets of information. The users may then decide if the changes received require any actions on their part.
Configurability – An important matter for aftermarket is the ability to configure product data for
analysis and preparations. With respect to visualisation not only the configured item in itself is of interest, but also the surrounding geometry. Especially service method preparations regard this issue since key elements of the work comprise clash analyses.
Traceability – It should be possible to trace and control information created and owned by product
development, which is used by aftermarket engineers. There is a need to keep track of changes, thus enabling work on the relevant information items. E.g. to keep track of visualisation data used to evolve and document a service method or training illustration. Inversely, the ability to relate aftermarket information items back towards the upstream structure is important as it can enable designers to take notice of the impact of certain analyses, e.g. a space claim for a disassembly.
System flexibility – Many off the shelf software applications adapted for aftermarket preparations are
highly specialised. Therefore, interoperability aspects towards existing PLM environments become important. The introduction of a best of breed approach in terms of supporting software for aftermarket analyses and preparations is advocated in terms of increasing productivity. The introduction of interactive 3D in aftermarket support products emphasise this even more.
Business flexibility – Means for managing a heterogeneous PLM environment are important in the
industry subject to study. Different departments or areas on the product development side are using different CAD and PDM systems. In connection to that, the upstream information interfaces need to be easily handled. If a single and open interface in cross-section between product development and aftermarket were to be provided it would ease daily work for aftermarket engineers, but it would also allow easier adaptation of enlarging the scope of aftermarket preparations.
4.2 Synthesis
There exist different architectural concepts that realises the needs conveyed in previous section. The use of a multi-CAD and multi-PDM environment for different areas of the products lead to difficulties for downstream processes to put together a comprehensive view of the product data. A consolidation of product data, including both structure and visualisation data is one step towards complying the business flexibility need. One application architecture concept could be to consolidate towards one single CAD system and one PDM system used upstream. Another option is to implement a middleware in between the heterogeneous PLM environment upstream and the systems and databases used downstream for analyses and preparations. We hereby refer to that alternative in terms of an Engineering Hub. Such a hub, as illustrated in Figure 2, should supply correct and relevant product structure and visualisation data to aftermarket engineers. It should furthermore provide a product configuration capacity, which should enable engineers to configure products according to their needs. Even though the hub in itself does not need to contain all upstream and downstream product data that exist, it should provide mechanisms for retrieving data and getting the user notified on changes in the data sets of interest. It should also supply the necessary tracelink between product development and aftermarket product data.
Engineering HUB PDM 1 PDM 2 CAD 1 CAD 2 ? Repair/Service Methods Service info 2d, 3d Parts Assortment Spare Parts Info Training, interactive 3d HQ Images Training/Marketing Feedback to projects Business flexibility Configurability System flexibility Correctness Traceability
Typical aftermarket products:
An Engineering Hub as outlined need to facilitate the provision of visualisation data. That could be data in native CAD format. However, technology movements in recent times have entailed the development of 3D lightweight formats [5, 6] as possible information carrier. Data provisioned on these formats reduces the need for storage capacity and reduces data transfer times significantly as the formats support enhanced data compression and streaming capabilities. Some of these lightweight formats are neutral with public specifications, e.g. the U3D [7] and JT [8] formats, which in turn enables software vendors to support them e.g. in applications adapted for aftermarket analyses and preparations. The additional provision of visualisation data in the Hub through a commonly used lightweight format would be to increase the ability to adopt a best of breed approach in terms of systems to be used on the aftermarket side. If all configurable visualisation data was to be provisioned through the Hub on a single lightweight format, difficulties would cease in terms of retrieving design data.
The overall picture provided in this section of an Engineering Hub constitutes the founding body for the discussion onward. The conception of a hub mechanism, as illustrated in Figure 2, is a promising way for realising the functional requirements stated in Section 4.1. It should however be emphasised that there are multiple ways of implementing an application architecture that encompass such Hub.
5 SUPPORTING TECHNOLOGY AND CONCEPTS
5.1 3D lightweight formats
PLM is greatly facilitated by access to 3D visualisation data. The original authoring of this data is mainly done in CAD systems and the data which these systems create usually has a format specific to the system, contains a lot of detailed information, and as a result, leads to file sizes which are relatively large. For most downstream PLM tasks it is sufficient to use only a portion of this information. Handling smaller amounts of data also increases the overall efficiency of downstream processes. This has been the incitement behind the creation of 3D lightweight data formats.
The advantages in using lightweight visualisation data are that a) it contains only relevant data, b) has a significantly smaller file size, c) has shorter data transfer and loading times, and considering downstream aspects, d) format originators have ambitions for a widespread use of their format which should lead to good availability of (inexpensive) vendor tools that can handle the format.
Apart from storing geometrical information, 3D lightweight formats may also contain textures and light sources, metadata, such as Product Manufacturing Information (PMI), and information regarding product structure. This information is sufficient for simple analyses, e.g. clearance measurements and collision recognition.
Basically, lightweight format file creation is a push from a part or an assembly. When the part/assembly is modified, the derived lightweight file needs to be recreated. The 3D lightweight file does not contain configuration data because it is a representation of a resolved configuration.
Among vendors and their 3D lightweight formats, the most notable are
• Adobe and Intel with U3D (Universal 3D). Adobe and Intel are the main sponsors behind the
3DIF Consortium which have chosen U3D as an industrial standard. The U3D format is used in Adobe’s Acrobat 3D, which enables 3D CAD models to be integrated into Acrobat products. Here, 3D PDF files are used with authoring technology from Right Hemisphere.
• UGS and the Open JT Consortium with JT (Jupiter Tessellation). UGS in the main sponsor of
the collaborative format JT and initiated the JT Open Consortium to help spread the format. JT is flexible, scalable, and toolkits are available to help 3rd-party developers to embed JT into existing applications which has lead to a broad range of these.
• Dassault Systemes and Microsoft with 3D XML. Dassault and Microsoft have a signed strategic
cooperation agreement to develop the 3D XML format. The 3D geometry representation in the 3D XML files is in the XVL format from Lattice Technologies which supports many CAD formats. 3D XML has currently only limited 3rd-party support.
• Autodesk with DWF (Design Web Format). Autodesk has chosen to support the use of DWF
through free DWF writers and viewers. Previously used mainly for CAD2CAD data exchange, the new Autodesk Design Review workflow is now helping non-CAD users to participate in collaborative processes using the format.
Common for these formats are that they in a varying degree are non-public. U3D and JT are in principal recognised as the most open formats, whereas 3D XML and DWF through the same view are recognised as the most proprietary ones.
Widespread use of a lightweight format is tied with its ability to provide for a wide range of needs. This has lead to the identification of the following key functionalities and capabilities to be associated with 3D lightweight formats.
1. Openness – referring to access of the data model describing the format
2. File size/compression rate – which influences the handling of format files
3. Quality levels/Level Of Detail (LOD) – which concerns the precision in geometric
representations
4. Performance – with regard to generation/load times and run-time memory consumption.
5. Product structure support – which determines the ability to handle configuration information
6. Support for 2D imagery, rendering data, animations and kinematics – which enables
documentation, visualisation, and dynamics
7. Management of metadata, attributes and references – which facilitates the addition of
information at the part file or assembly node level
8. Application and format generation support – which gives the freedom of choice of format tools
Distribution of 3D lightweight data to aftermarket and the realisation of the Engineering Hub concept led to the conclusion that (1), (8), (4) and (5) are to be considered as the most prioritised aspects. With respect to Openness, increased competition among vendors of applications supporting the format tends to lead to a wide range of (inexpensive) and rather high performing tools. Abundance of applications supporting the format and the availability of translators from proprietary CAD to 3D lightweight formats increases the attention that must be set on Application and format generation support. The
Performance issue include the need for acceptable loading speeds (including on-the-fly conversions)
and run-time memory consumption. To conclude, Product structure support is a mean for variant and configuration information management.
5.2 Configuration and change management
There exist several descriptions of what configuration management is. In the context of aftermarket and its needs to configure visualisation data throughout the development process, ISO [9] provides a sufficient definition. Product configuration is concerned with the description of the composition of specific products, which includes specification of the actual constituents of a planned or actual product.
In the context of design work and aftermarket engineers’ utilisation of visualisation data it is important to distinguish between non-configured structures on a type level and configured structures on a planned product level. All geometries are not subject to configuration control, especially not in conceptual design phases. But those that are, must be made available for downstream use. In addition, the configured parts or assemblies in focus must include a surrounding geometry component. In turn, these set hard demands on the configuration system, including processes and tools, that are needed to support these engineering activities.
The product definition changes and matures throughout the development process. From a product data management perspective, we refer the efficient administration of this phenomenon to the concept of change management. Again, according to ISO [9], change management involves the changes over time in a product as new versions of a product and/or it constituents are developed. An important aspect of change management regards traceability, which is the possibility to trace consequences of a possible or conducted change in one area to another area of the product. In the case of synchronous product and aftermarket support development, the ability to understand and to manage changes in the product definition towards e.g. maintainability analyses becomes obvious.
Facilitation of a cross-functional change management is one of the cornerstones that must be provided in the realisation of an Engineering Hub. It should encompass means for traceability on a configured item or assembly level, between the as-designed and the as-maintained views of a product, thus enabling engineers of different domains to act efficiently the development process.
5.3 Supporting architecture
From an application architecture point of view there are at least two extremist concepts that are possible to use for implementing a solution that supports the needs, given that off-the-shelf software
should be utilised. One concept comprises the exploitation of a very limited number of softwares, for virtual product and aftermarket support development. Softwares should be selected to secure a very high level of data interoperability between applications deployed in different engineering domains. The other concept aims at facilitating an open architecture and allows the adopting of a best of breed approach in terms of software deployment in different engineering disciplines across the PLM ecosystem. In this case, data interoperability is secured through manifested data interfaces between applications.
The first concept has the result that the vendor(s) becomes the owner of the information architecture, and that the business becomes heavily dependent. An advantage is the company (customer) does not need to get profoundly involved in development and maintenance of application interfaces. The second concept necessitates a large engagement in information architectural issues, and thus also interfaces issues regarding application-to-application data communication. An advantage related to this concept regards liberty of action in terms of introduction and phase out of particular applications. It is advocated that an open architecture best oblige to the conditions for aftermarket. That prerequisite does however emphasise the importance of a distinct information architecture, i.e. definition of concepts, semantics and data structure. Good support for elucidating the corporate information architecture can be found in various industry standards, e.g. in STEP [10]. Such standard can be either use as-is or customised to a particular need. A high level of conformance towards industry standards increases the prerequisites for succeeding in achieving easy to develop and easy to maintain application integrations, and is thus beneficial also from an economical standpoint. A trend in today’s PLM is Service Oriented Architecture (SOA), which aims at formalised methods of integrating applications into the enterprise architecture [11]. In short, SOA is an architectural style that separates implementation of services (functionality) from the service consumers. One frequent realisation of SOA is that of web services [12], which make up a standardised interface for information exchange. Enabling web services are now emerging in the PLM area [13, 14]. A very clear advantage with SOA and web services are that maintenance costs can be kept to a minimum, and that they facilitate means for providing flexibility in terms of choosing PLM components.
6 RESULTS
With respect to technology aspects and identified concepts it is possible to evolve a conceptual application architecture that has the potential of being a further step forward. The architecture, see Figure 3, does not in particular consider information and infrastructure aspects other but peripheral. At first, we recognise that an Engineering Hub must provide some means for data retrieval. It should then be possible to search, navigate and select product structure and visualisation data through an easy to use interface. The kinds of information concepts of interest are product structure and part information, including version and effectivity attributes. Also, additional information such as application context (e.g. functional possession) and configuration defining information is needed. It should be possible to retrieve all this information through the Hub user interface without having to manually find it in an abundance of CAD and PDM systems. Addressing these issues is fulfilling aftermarkets’ need regarding Correctness, and constitutes the first step in meeting the Traceability and
Configurability needs.
Visualisation data in the Hub should be made accessible on a format that enables any particular organisation to identify, download (export), and preferably use it in a specialised tool for analysis and preparation. This export should facilitate the preservation of product structure and related information to a feasible level, seen from a downstream perspective. This brings the usage of a 3D lightweight format to the fore. With respect to ease of implementation (Openness and Product structure support aspects, see Section 5.1) and eager to adopt a best of breed approach in terms of application strategy downstream (Application and format generation support, see Section 5.1), it is seen as a necessity that an Engineering Hub, as described, should be able to provide all visualisation data through a single 3D lightweight format. However, native data from CAD is likely to be needed in a minor set of applications in the future, which in turn drives the issue of also making such data accessible in the Hub as well. To sum up, the need for System flexibility is to be met by this provision of visualisation data. Furthermore, it should be possible to access product structure and visualisation data of varying maturity. Early phases of concept design are likely to include only a very limited set of released product configurations. Hence, there is a need to provide a mechanism for retrieving non-released CAD & PDM data, e.g. from personal layouts. In this manner, early aftermarket analysis and
preparation is not prevented, even though such case is not likely to be the most common one with respect to the entire development lifecycle. Typical information managed in DMU tools in the product development domain is what should be provisioned to the Hub. The Traceability and Configurability needs are hereby met.
The first step towards a cross-functional change management is to enable engineers to keep track of changes in the product data of interest. The facilitation of an automated (or semi-automated) tracking of changes in the used set of information is needed for a reasonable level of work efficiency. It is very conceivable that some kind of subscription and notification service is needed, which relates to product structure items of concern. The Hub in itself does not necessarily need to contain all data of interest (if implemented as a stand alone solution), but should provide means from retrieving, tracing and keeping track of change information. Thus, the Correctness need is even met further by the concept.
The Engineering Hub should also allow referencing of information to allow provision of feedback information. Thus, there is a need to tie feedback information created by any user to a specific information “baseline”. An example of such feedback information is a resulting space claim from a disassembly analysis performed by an aftermarket engineer. This emphasise the need for an instrument that enable downstream users to add data items to the structure provided by product development. This addresses the Traceability issue.
Thoroughly manifested information interfaces upstream and downstream the conception of an Engineering Hub are required to enable upstream Business flexibility. The better these comply with accepted standards and courses of action in industry, the better prerequisites to succeed.
Engineering HUB PDM 1 PDM 2 CAD 1 CAD 2 ? Repair/Service Methods Service info 2d, 3d Parts Assortment Spare Parts Info
Training, interactive 3d HQ Images Training/Marketing Feedback to projects Engineering HUB PDM 1 PDM 2 CAD 1 CAD 2 ? Repair/Service Methods Service info 2d, 3d Parts Assortment Spare Parts Info
Training, interactive 3d
HQ Images Training/Marketing Feedback to projects
Engineering Hub with • Product structures • Part information • Geometry information in lightweight format • Positioned product configurations with surroundings • Cross-functional change management based on effectivity • Subscription & notification services
DMU tool for released data
CAD & PDM data for non-released data
Hub navigation and information selection tool
Using e.g. web service integration
Specialised tools for analysis and preparation
Structure and visualisation data export
Figure 3 Conceptual architecture of the Engineering Hub concept
7 SOFTWARE PROTOTYPE
A software prototype implementing the conceptual architecture was built within the study related to this work. It was build in order to verify the results, i.e. the basic Engineering Hub concept. The overall setting for the prototype was service method preparation and aftermarket engineers’ feedback to designers. The prototype was thus delimited to focus scenario 1 and 2, see Section 3. The industrial setting and the used product data were authentic from a commercial vehicle company. The replace (exchange) method for a compressor was used to illustrate the overall concept. The compressor in itself is designed in a number of variants, and is planned for use in a multiplicity of product configurations. The overall aftermarket goal is to keep the number of service method variants for the compressor to a minimum. Furthermore, the compressor’s positioning in the product assembly is quite intricate as space for disassembly is limited. In addition, the surrounding geometry in some way needs to be retrieved and compiled from data managed in three different CAD vaults, as a result of the industrial setting. As a preparatory step, live product structure and native visualisation data was manually retrieved from multiple CAD vaults and then converted into the JT 3D lightweight format.
This data was semi-automatically stored in commercial software; Share-A-spaceTM [15], which conceptually realises some of the basic features wanted for the Engineering Hub. Another part of the prototype system was a visualisation mock-up tool, to use for aftermarket analysis related to the method development. In reality, it was only loosely coupled to the Hub, even though the eye should perceive a tight integration. The software used for realising the analysis tool became Teamcenter Visualization Mockup [16].
Feasibility of the system was tested through a basic workflow with firm anchorage in the business’ needs, see Figure 4. It included a typical user scenario and encompassed 1) search for a certain product in the Hub, 2) retrieval of product and surrounding geometry, 3) assessment of result in the Hub, 4) export of data to system for analysis, 5) service analysis (in this case resulting in a space claim), 6) publication of aftermarket product data, 7) and finally, setup of a subscription profile for product data related to the performed analysis.
Publish analysis result in the Hub
6
Publish analysis result in the Hub
6
Setup subscription profile7
Setup subscription profile7
Order product with desired configuration
Visualisation Study
Volvo Group IT-Governance Olaf Tellefsen and Trond Zimmerman, November 07, 2006 Slide 30
Volume filter, Inner box Volume filter, Inner box Volume filter, Outer box Volume filter, Outer box Volume filter, selection Volume filter, selection Partly in Partly in Variant String Variant String Function Group Function Group Project Project
2
Order product with desired configuration
Visualisation Study
Volvo Group IT-Governance Olaf Tellefsen and Trond Zimmerman, November 07, 2006 Slide 30
Volume filter, Inner box Volume filter, Inner box Volume filter, Outer box Volume filter, Outer box Volume filter, selection Volume filter, selection Partly in Partly in Variant String Variant String Function Group Function Group Project Project
2
Export items of interest to downstream system
Visualisation Study
Volvo Group IT-Governance Trond Zimmerman & Per Brorson, January 17, 2007 Slide 41
4
Export items of interest to downstream system
Visualisation Study
Volvo Group IT-Governance Trond Zimmerman & Per Brorson, January 17, 2007 Slide 41
4
View the result in the Hub
3
View the result in the Hub
3
Search for product in the Hub
1
Search for product in the Hub
1
Compressor
example
5
Perform analysis in downstream system5
Perform analysis in downstream systemFigure 4 Software prototype
The prototype system did not concern all aspects, analyses and systems that need to be supported on the aftermarket side. But through the scenario represented by the basic workflow it illustrated the basic principles. The effort supported the presumption that 3D lightweight formats are sufficient for consumption by aftermarket engineers, besides feasible for consolidation of heterogeneous sets of native CAD data. Several user groups at the company subject to the related study have been introduced to the overall ideas and concepts. As part of that they have scrutinised the software prototype system. The reception from these user groups has been predominantly positive. Even though not implemented in the prototype, principal applicability of the system with respect to scenario 3 to 6, see Section 3, was judged as feasible. Validity of the Engineering Hub feasibility has by these means been verified.
8 DISCUSSION
Distribution and use of visualisation data for aftermarket, but also for other downstream functions, can be facilitated through the deployment of 3D lightweight formats. Their use fit into the overall concept for distribution of product data presented in this work, i.e. the Engineering Hub. To improve the
prerequisites for ease of implementation and maintenance openness (non-proprietary) aspects are important in the choice of format(s). It is also important to minimise the resulting delimitation that is attached to a certain choice of format with respect to the possibilities to deploy software components in the downstream PLM ecosystem.
A means for complying with the information needs of a aftermarket business is to make product structure and visualisation data accessible through the conception of an Engineering Hub. Such Hub should fit into an open architecture by defining the standards and technologies to be used. In this connection, it is important to define the information interfaces between areas of application. This relates to the open architecture idea and is a requisite for the realisation of the needed services for data exchange between systems.
A solution that enables aftermarket engineers to search and select precisely the data needed will make their work more pliable and efficient. Solution features related to the Engineering Hub concept such as upstream/downstream traceability, cross-functional change management and notification services are important added value to the basic configuration concept. An Engineering Hub with considerable configuration capabilities is a requisite for creation of efficient workflows in the aftermarket business. Such a solution should provide means for downstream structure creation, work and reuse. Implementing the Hub concept will however require a lot of focus and further elaboration on virtual development methods in the aftermarket business.
9 CONCLUSIONS
The condensed remarks that concludes this work are as follows
• The choice of lightweight format as a mean to efficiently consolidate and distribute geometry
data is a key issue in providing flexibility for businesses in managing a multi-CAD/PDM environment and utilising a best-of-breed approach with respect to choices of engineering tools.
• Lightweight formats build on open and publicly available standards is important for minimising
risk and maximising freedom of action in terms of implementing a robust architecture for distribution of geometry data.
• The ability to adapt product configurations according to the own cross-functions needs is one of
the most important abilities to enable concurrent engineering in early development phases.
• Consolidation of product development and cross-functional information must be enabled
throughout the development process as a mean to effectively manage the evolution of the technical system (product, production and services).
• The conception of an Engineering Hub for consolidation of upstream and downstream
information is a realistic way of meeting cross-functional information needs.
• Such an Engineering Hub must be able to provide functionality such as product structure and
visualisation data management, cross-functional change management, besides subscription & notification services regarding changes, in order to support the basic downstream information needs.
• Establishing a single point of contact for cross-functions to evaluate and retrieve product
structure and geometry data, given a heterogeneous system environment and a multi-CAD/PDM landscape is an effective instrument for increasing productivity and quality of engineering work.
• The ability to subscribe to, and receive change notifications on delimited sets of the product
definition is a mean to attain effectivity in daily engineering work.
10 FUTURE WORK
Applicability of ideas and concepts provisioned through this work should be tested in other downstream domains, e.g. virtual manufacturing and sales. As the industrial trend is that suppliers are getting more and more involved in product development, in earlier phases, with larger responsibilities than before, this work’s ideas and concepts could be tested as a mean to provide a feasible level of transparency also there. Building all management and distribution of product data on the same principles, i.e. with similar processes, tools and methods, independently of whether the information receiver is an downstream actor or a supplier has the potential of increasing synergies, and thus, to save resources when further implementing the PLM system.
ACKNOWLEDGEMENTS
This work was financed by Volvo Information Technology AB and the Swedish Foundation for Strategic Research’s ProViking programme. Their support is gratefully acknowledged.
REFERENCES
[1] Fuxin, F. Evolution and Communication of Geometry Based Product Information within an
Extended Enterprise, Doctoral Dissertation, Division of Computer Aided Design, Luleå University of Technology, Sweden, 2005.
[2] Karandikar, H. et al. Moving Product Information Along the Value Chain: Overcoming
Challenges of Distributed Organizational Structure and a Heterogeneous Information Environment, ASME International Design Engineering, Philadelphia, Pennsylvania, USA, 2006, Document Id. DETC2006-99194.
[3] Vielhaber, M., Burr, H. and Eigner, M., Product Structuring for Cross-XPDM, International
Design Conference – DESIGN 2006, Dubrovnik, Croatia, 2006, pp. 655-664.
[4] Zimmerman, T., Bergsjö, D. and Malmqvist, J., Coordinating the Engineering and Aftermarket
Disciplines in Early Phases of Product Development, Nordic Conference on Product Lifecycle
Management – NordPLM’06, Göteborg, 2006, pp. 1-13.
[5] Russell, P. S. et al., STEP, XML, and UML: Complementary Technologies, Journal of
Computing and Information Science in Engineering, Vol. 4, 2004, pp. 379-390.
[6] ProSTEP iViP Association, “Analysis of Cross-Enterprise Exchange of Visualization and
Assembly Data”, White paper, http://prostep.org/en/standards/doku/, retrieved 2007-01-21.
[7] ECMA TC 43, ECMA-363 Universal 3D File Format, 3rd edition, Geneva, Switzerland, 2006.
[8] UGS, JT File Format Reference Version 8.1, Specification,
http://www.jtopen.com/docs/JT_File_Format_Reference.pdf, retrieved 2007-01-08.
[9] ISO TC 184/SC4, ISO 10303-44: Industrial Automation Systems and Integration – Product Data
Representation and Exchange – Part 44: Integrated generic resource: Product structure configuration, Geneva, Switzerland, 2000.
[10] ISO TC 184/SC4, ISO 10303-1: Industrial Automation Systems and Integration – Product Data Representation and Exchange – Part 1: Overview and Fundamental Principles, Geneva,
Switzerland, 1994.
[11] McGovern, J. et al., A Practical Guide to Enterprise Architecture, 2004 (Prentice Hall, Upper Saddle River).
[12] Johansson, B., Model Management for Computational System Design, Doctoral Dissertation, Department of Mechanical Engineering, Linköping University, Sweden, 2003.
[13] Rachuri, S., Foufou, S. and Kemmerer, S., Analysis of Standards for Lifecycle Management of Systems for US Army --- a preliminary investigation, National Institute of Standards and Technology Report, 2006, Document Id. NISTIR 7339.
[14] Zimmermann, J. U., Information Integration of Product Development Software in the
Automotive Industry – The Uleo Approach, Doctoral Dissertation, 2005 (University of Twente). [15] Johansson, M., Sharing Product Data Through Life in the Extended Enterprise – the
Share-A-space™ solution, White paper, http://www.share-a-space.com/pressroom.asp, retrieved 2007-01-25.
[16] UGS, Teamcenter Visualization Mockup fact sheet,
http://www.ugs.com/products/teamcenter/docs/fs_tc_vis_mockup.pdf, retrieved 2007-06-08. Trond Zimmerman
Volvo Information Technology PLM Solution Center Dept 9143, PVV3:1 SE-405 08 Göteborg Sweden +46-31-3226342 [email protected]
