Anna Tidstam
email: anna.tidstam@chalmers.se

Johan Malmqvist

Comparison of configuration rule visualizations methods

Keywords: configuration rules, visualization, authoring

The aim of this paper is to compare matrix-and list-based configuration rule visualization methods in order to find the effects of using a certain visualization method. Especially, the visualizations' impact on readability and how the configuration rules are authored are studied. A case study was conducted at two automotive manufacturing companies. The research method included to observe users as they were authoring configuration rules, to study the visualization methods, and to interviews users of the PDM system visualizing the configuration rules. It was found that common aim for the users is to author easy to read configuration rules, which this paper shows is highly dependent on the visualization method. The conclusion is thereby that the choice of visualization method influence how the configuration rules are authored.

Introduction

Configurable products are specified by a set of alternative product features. Cars are often configurable, with alternative product features including engine sizes and exterior colors. To assure that the specification of a configured product belongs to the developed product offering, there are logic expressions. An example of those logic expressions is that the exterior color red is not offered with engine size 1.8 liters. Such logic expressions are in this paper called configuration rules following the definitions in [START_REF] Barker | Expert systems for configuration at Digital: XCON and beyond[END_REF][START_REF] Soininen | Developing a declarative rule language for applications in product configuration[END_REF]. Moreover, configuration rules validate the correctness are according to [START_REF] Barker | Expert systems for configuration at Digital: XCON and beyond[END_REF] rules for validating the correctness of customer orders and for guiding the actual assembly of these orders. A similar explanation is used in [START_REF] Soininen | Developing a declarative rule language for applications in product configuration[END_REF], where configuration rules are the rules for how the components can be combined to form a product. One of the main difficulties with large sets of configuration rules is the maintenance, in other words modifying the configuration rules following a product offering modification [START_REF] Bachant | R1 revisited: Four years in the trenches[END_REF]. To be able to maintain the configuration rules, there is a user interface with a visualization of configuration rules. A visualization of configuration rules is a representation of configuration rules for communication of configuration rules to a user. The visualization of configuration rules is a kind of information visualization. The aim of information visualization is to create an effective representation of the information model and the information contained therein [START_REF] Mackinlay | Automating the design of graphical presentations of relational information[END_REF]. Effectiveness means that the user as quickly as possible gets an overview of the information. The effectiveness is chal-lenged for the configuration rule visualization as there may be hundreds of thousands of configuration rules.

Some researchers have studied different methods for visualization of configuration rules, for example matrices: K-and V-matrix [START_REF] Bongulielmi | The K-& V-Matrix-Method in Comparison with other Matrix-based Methods supporting Modular Product Family Architectures[END_REF], and trees: Product Family Master Plan [START_REF] Harlou | Developing product families based on architectures -Contribution to a theory of product families[END_REF] and the Variant Tree [START_REF] Schuh | Variantenreduzierung im Verbund -Praktikable Methode zum Variantenmanagement: Ein Leitfaden zur Beherrschung der Variantenvielfalt[END_REF]. The mentioned previous research is however not empirical studies with configuration rules from the automotive industry. Earlier studies have shown benefits of matrix-based methods for configuration visualization [START_REF] Tidstam | Authoring and Verifying Vehicle Configuration Rules[END_REF]. For example, a matrix organizes data into a structured overview that is difficult to achieve with a list of text strings. The advantages and disadvantages specific to configuration rules have however not been fully studied. There is a list-based configuration rules visualization from an automotive company in [START_REF] Hami-Nobari | Effect-oriented Description of Variant Rich Products[END_REF], but unfortunately this visualization is not in detail described nor evaluated. If the configuration rules cannot be effectively visualized, an alternative approach is to change representation as for example mathematical equations on design parameters which was suggested in [START_REF] Hami-Nobari | Effect-oriented Description of Variant Rich Products[END_REF].

The authoring, i.e. the creation and modification, of configuration rules depends on the user: some users prefer a set of few but long (many product features) configuration rules, while others prefer a set of many but short (few product features) configuration rules [START_REF] Tidstam | Authoring and Verifying Vehicle Configuration Rules[END_REF]. The main aim with this paper is to compare configuration rule visualization methods in order to find the effects of using a certain visualization method, especially the impact on how the configuration rules are authored. A second aim is to find advantages and disadvantages for the visualization methods at the two automotive manufacturing companies. The following research questions have been addressed:

RQ1: What are the characteristics of the authoring methods for configuration rules that may be derived from the use of either matrix-or list-based visualization methods?

RQ2: Which visualization method is most suitable in the cases of: (a) high number of configuration rules (b) high number of product features in each configuration rule?

The remaining of the paper is organized as follows: In Section 2 the research method is described, Section 3 presents the results, Section 4 discusses the results and in Section 5 the conclusions are stated. Finally, in Section 6 future work is proposed.

Research Method

This paper studies the configuration rules visualization methods at two major European automotive manufacturing companies, henceforth called Alpha and Beta.

The research study was conducted during a 3 months stay at Beta in the team of configuration rules specialists, which was an adequate time-frame for revealing the process of authoring configuration rules as well as getting acquainted with the PDM backbone systems at Beta. During this time, several workshops were arranged with Alpha, which gave the possibility to compare both authoring and visualization methods. As seen in Fig. 1, the research process was structured into three phases: analysis, testing and evaluation. In the analysis phase, the authoring and visualization of con-figuration rules were described. Then in the testing phase, the configuration rules at Beta were tested with Alpha's visualization method. This comparison was later evaluated during the evaluation phase by interviewing three configuration rules specialists with various years of experience (4-30 years) at Beta.

Results

The result section is divided into three sections: 3.1 Analysis phase, 3.2 Testing phase and 3.3 Evaluation phase.

Analysis phase

In this section, a use case scenario is used for describing authoring and visualization methods at Alpha and Beta. The use case describes the authoring of configuration rules for a new feature variant a3, e.g. orange exterior color. New feature variants do not have any configuration rules initially, and the use case is to author the required configuration rules. Feature variant a3 belongs to feature family A (e.g. exterior color), which already contains the feature variants a1 (e.g. red) and a2 (e.g. green). Both Alpha and Beta use codes for feature families and feature variants.

Authoring and visualizing configuration rules at Alpha. The purpose of this section is to show the principles for how to author configuration rules at Alpha (using their matrix-based visualization method), which is then followed by another section for Beta (using their list-based visualization method).

The authoring process at Alpha consists of three steps: Step 1 is to visualize existing configuration rules, Step 2 is to update the feature family relationship, and Step 3 is to assign configuration rule values. The authoring of configuration rules is thereby prepared in Step 1, and actually performed in Step 2 and 3.

Step 1 is to visualize the configuration rule matrix for feature family A, as shown in Fig. 2. The systematic configuration rule value (S) indicates that only particular combinations of feature variants are allowed. The only allowing configuration rule for a1 is IF a1 THEN (m1 AND n1), e.g. IF red THEN (engine V6 AND sport package). The minus signs restrict feature variant combinations, e.g. NOT (a1 AND m2 AND n1).

THEN

Feature families

Feature variant combinations

M m1 m2 N n1 n1 Feature family Feature variant IF A a1 S - A a2 - S A a3 - -

S = systematic and -= not allowed

Fig. 2. An example of Alpha's configuration rule matrix. This visualization is studied during the first step in authoring configuration rules at Alpha.

Step 2 is to update, if necessary, feature family A's relation, see Table 1. Feature family relations are the source data for the generation of any configuration rule matrix. In this use case scenario, it is assumed that feature family P is required because of the addition of feature variant a3. Step 3 is to assign configuration rule values, see Fig. 3. The new optional configuration rule value (O) for a3 is the feature variant combination m2 AND n1. Among optional configuration rule values, there is a default configuration value (D) which is the preferred feature variant combination. The configuration rule value for a2 also needs to be updated as it is no longer the only allowed feature variant for combination m2 AND n1. The authoring and visualization of configuration rules at Alpha have now been described, and now it will be shown hot the same operation is performed at Beta.

IF A a1 S S - - A a2 - - D D A a3 - - O O S =
Authoring and visualizing configuration rules at Beta. The same use case scenario is used when described in the authoring method at Beta: Step 1 is to visualize the existing configuration rules, and Step 2 is to author the configuration rules.

Step 1 in the use case is to visualize configuration rules for a1 and a2, see Table 2. The purpose of Step 1 is to find frequently used feature families, for example all engine sizes can have configuration rules with gear box alternatives. The configuration rules at Beta may include both positive (AND, OR) and negative operators (NOT). Step 2 is to author the configuration rule for a3, see Table 3. As the customer may choose between a2 and a3, also the configuration rule for a2 has to be re-formulated.

Notice that there is no difference between default and optional feature variant combinations at Beta, as this distinction is managed the separate sales system. The analysis phase is thereby ended and the next section will describe the testing phase.

Testing phase

The purpose of the testing phase is to find relevant measures for the matrix-and the list-based visualization methods and thereby compare those using three real case examples. The real case examples were selected based on the users' at Beta interest in trying challenging examples, for instance configuration rules with extremely many configuration rules or extremely many feature variants within the configuration rules. One of the real case examples visualized with matrix-based method is shown in Fig. 3. Two measurements have been established: a size measurement G in the growth direction (number of columns for the matrix, number of rows for the list), and a combinatory difficulty measurement C which is the number of feature variants combined in a configuration rule. The number of columns in Fig. 4 is 10, but note that the number of columns is here reduced, as for example the empty cells for the row of feature family P could be filled with any of p1 or p2. The combinatory difficulty measurement is equal to the number of rows with feature variants in the matrix, which is 9 in Fig. 4. The number of configuration rules, could be counted as a range between 1-10, as the configuration rule values could be combined with the OR-operator. The test result summary for the three real case examples and the measurement in the growth direction (G) is shown in Table 4. The trend is that the number of matrix columns is higher than the list rows, which may be a disadvantage when using a ma-trix-based visualization method. The combinatory difficulty measurement (C), shown in Table 5 does not show a clear trend. The matrix-based visualization can, but not necessarily, have a combinatory difficulty within the range of the list-based visualization method. It all depends on how the configuration rules are authored and which configuration rules that are visualized together.

Evaluation phase

Three semi-structured interviews were held with configuration rules specialists from Beta, where they commented on the benefits and disadvantages of the matrix-and the list-based visualization method based on the real case example from the previous section. During the interviews it was found that the advantages of using the matrix-based visualization method were dominating. Arguments were that the list-based configuration rules at Beta were similar to programming with many symbols for Boolean operators and complicated use of brackets. The matrix-based visualization method does not contain any explicit Boolean algebra (signs such as OR (/), AND (,), NOT(-), AND-NOT ( +-)). One quotation from an interviewee's comments is:

Our PDM system [with list-based visualization method] contains Boolean algebra which is for few people understandable, especially since we combine so many +,and (). The matrix [without any explicit use of Boolean algebra] is in general always easier to overview and understand.

The non-specialists at Beta have great difficulties in reading the Boolean algebra in the configuration rules. This is in contrast to the non-specialists at Alpha who are competent to review the configuration rule matrixes at monthly meetings, and as well as soon there is a modification need.

Discussion

The main aim of this paper is to compare configuration rule visualization methods in order to find effects of how configuration rules are authored from using a certain visualization method. A second aim is to find advantages and disadvantages of the visualization methods at the two automotive manufacturing companies. The following research questions have been addressed: RQ1: What are the characteristics of the authoring methods for configuration rules that may be derived from the use of either matrix-or list-based visualization methods?

Overall, people not familiar with the authoring of configuration rules may find it difficult to even compare the use of matrix-and list-based visualization methods. For experienced users, the probably most striking difference is that, in contrast to Beta, Alpha has a visualization method generated from feature family relations. The feature family relations are extremely important for the configuration rule matrix, as reducing the number of feature family relations is the only way users can prevent the number of matrix columns from becoming high. The user wants to have few matrix columns in order to have an easy overview configuration rule matrix. Few feature family relations give short but many configuration rules.

At Beta, it is instead the number of rows in the configuration rule lists that the users are trying to prevent from growing. That is another optimization objective, causing the configuration rules to differentiate from Alpha's configuration rules: Beta authors long but few configuration rules. The combinatorial difficulty is then higher for a list than for a matrix when the users aim for an easy to overview visualization of configuration rules.

RQ2: Which visualization method is most suitable in the cases of: (a) high number of configuration rules (b) high number of product feature variants in each configuration rule?

Answering RQ2a: A high number of configuration rules potentially cause the visualization of configuration rules to become, independently of the visualization method, unmanageable big. The disadvantage of the matrix-based visualization method is that the number of matrix columns can potentially grow faster than the number of rows in the list-based visualization. This was shown in the tests conducted in this paper, where all three tests examples had this behavior. When there is a high number of configuration rules to be visualized, the list-based method has the advantage there are many logical operators that could be used in order to prevent the number of rows to grow rapidly. The recommendation is therefore to use a configuration rule list when a high number of configuration rules are visualized.

Answering RQ2b: A high number of feature variants in combination causes combinatorial complexity. The benefit of the matrix-based visualization is that is does not have the OR operator; there are only the operators AND and NOT. This is a very important fact, as it is the OR operator that enables the high number of features variants in combination. Without the OR operator, the configuration rule has to be visualized using several shorter configuration rules, with lower combinatorial difficulty and thereby easier to read. Based on this discussion, the conclusion is that the matrixbased visualization method is well suited for visualizing configuration rules with a high number of feature variants in combination.

Conclusions

The visualization method strongly influences how the configuration rules are authored, as there are different optimization goals for readability (few matrix columns vs. few list rows) and availability of logical operators (with vs. without OR operator). There are therefore obstacles when changing visualization methods, here summarized below.

From a list-based visualization method to a matrix-based visualization: the matrix will potentially get many columns.

From a matrix-based visualization to a list-based visualization: the strength of the list is not shown until the configuration rule are reformulated with the introduction of the OR operator.

The interviewed configuration rules specialists however strongly preferred the matrix-based visualization method even when admitting the strength of the list-based visualization method. The main argument was that the matrix-based visualization kept the Boolean algebra simple as it did not allow any OR operator. With a simple Boolean algebra, the configuration rules are becoming easier-to-read for all users working with configuration rules and that would make the development of configuration rules more efficient.

Future work

The three examples tested in this paper were selected on the basis of the users' wishes to test the visualization methods' strengths and weaknesses on challenging examples. Challenges in this context mean that the users had either a high number of configuration rules, or a high number of feature variants in each configuration rule. This is similar to a stress test, where a concept is tested under extreme conditions. A suitable continuation would be to build a prototype that the users could test under normal work conditions, which could capture more opinions of strengths and weaknesses of the two visualization methods.

Fig. 1 .

 1 Fig. 1. Overview of applied research methods.

Fig. 3 .

 3 Fig. 3. Configuration rule matrix with updated configuration rule values for feature variant a3, which is done during the third and last step in authoring configuration rules at Alpha.

Fig. 4 . 5 .

 45 Fig. 4. Alpha's configuration rule matrix with the measurements relevant for the tests (number of feature variants, number of feature variant combinations) marked out.The same example with Beta's original authoring of configuration rule list is shown in Fig.5. The number of rows are 5 for measurement G, and the combinatory difficulty measurement C (number of feature variants in a configuration rule) is a range 3 to 12.

Fig. 5 .

 5 Fig. 5. Beta's configuration rule list with the measurements relevant for the tests (number of configuration rules and maximal number of feature variants) are marked out.

Table 1 .

 1 Feature family A with its relation left) before update with P and right) after the update.

		Before update	After update
	IF	THEN	IF	THEN
	Feature family Feature families	Feature family	Feature families
	A	M, N	A	M, N, P

Table 2 .

 2 List-based visualization of configuration rules studied for finding frequently used feature families that could be suitable to use for authoring of configuration rules for a3.

	IF	THEN
	Feature variant	Feature variant combinations
	a1	m1 AND n1 AND NOT(a2)
	a2	m2 AND n1 AND NOT(a1)

Table 3 .

 3 List-based visualization of configuration rules with new configuration rules for a3, and updated configuration rule for a2.

	IF	THEN
	Feature variant	Feature variant combinations
	a1	m1 AND n1 AND NOT(a2 OR a3)
	a2	m2 AND n1
	a3	m2 AND n1

Table 4 .

 4 Test results of measurements growth direction measurement (number of columns vs. rows) for three real case examples (A-C).

	Company	Alpha (matrix-based visualization)	Beta (list-based visualization)
	Growth measurement	Number of columns			Number of rows
	Example A	8	is more than	4
	Example B	12	is more than	9
	Example C	10	is more than	5

Table 5 .

 5 Test results of combinatory difficulty for three real case examples (A-C).

	Company	Alpha			Beta
		(matrix-based visualization)	(list-based visualization)
	Combinatory difficulty	Number of feature variants in combination
	measurement
	Example A	3	is less than	max 4
	Example B	41	is more than	max 34
	Example C	9	is less than	max 12

Acknowledgements. This work was carried out at the Wingquist Laboratory VINN Excellence Centre for Efficient Product Realization at Chalmers University of Technology, supported by the Swedish Governmental Agency for Innovation Systems (VINNOVA). Further financial support was received from ProViking. For supervision during the industrial stay the first author would like to thank Hr. Eiffinger.


Mohd Frédéric Noël
email: frederic.noel@grenoble-inp.fr

Azwan Azli
email: mohdazwan.azli@gmail.com

Experimenting new metaphors for PDM through a Model Driven Engineering scheme

Keywords: PLM, PDM, Visualisation, Interaction, Complexity, Virtual Reality, Model Driven Engineering, Intuitiveness

Manufacturing companies invested a lot in Product Life Management (PLM) system to save their competitiveness by a better management of their internal processes. The most deployed systems are Product Data Management tools. By deploying such systems they try to formalize complex behaviour of the company. But PLM systems did not solve complexity and new gaps must be managed. At this point, it may be interesting to investigate new ways to overpass the new complexity gap. On another hand Virtual Reality, Augmented Reality and every other Visualization and Interaction technologies are investigating more intuitive modality to interact with information, but these technologies remain quite unused for PDM applications. This paper proposes the Model Driven Engineering horizontal transformation approach to provide a systematic way to explore Virtual Reality opportunities within the PDM scope.

Introduction

The WP5.1 IFIP working group manifesto notes [START_REF]IFIP Working Group 5.1. Ifip working group 5.1 manifesto[END_REF] that "Understanding the whole life-cycle impact of products is a critical issue in product development today". When the product development remains quite simple there is no rationale to deploy PLM. But indeed the increasing complexity of product and processes is a major trigger of technical evolution of PLM issues within industry. CAD system as many other simulation tools were a first answer to accelerate expert tasks and was a very good answer to support individual activity. But indeed as soon as more collaboration is expected, sharing information between experts became a new challenge. This step towards complexity was passed in the 80s and first Product Data Management systems appeared to answer this basic issue. It was first deployed at the service/team level where every expert has a good understanding of the colleagues activity. But complexity increased once again with both the necessity to share information at the company level, or between various stakeholders. Simultaneously, the number of actors and the number of expertises are increasing.

PLM claims to provide an holistic view, and thus, to pass over this last complexity step. But complexity of product life management remains a challenge. Product data Management tools (PDM) are the main component of the PLM toolbox: PDM appears as not so intuitive; sometimes as complex as the problem they are expected to solve. This paper makes the assumption that every information is at the end processed by users through various metaphors (indeed mainly graphical metaphors). The complexity appearance is thus included in the proposed metaphors and may be reduced by the exploration of new visualization modalities. The aim is to propose some solutions to decrease complexity of PDM solutions by using some virtual reality opportunities.

The paper focusses first on an overall Product Data Management (PDM) description to highlight its main concepts and functions. Section 3 presents the main added value of virtual reality technologies. Virtual reality (VR) is a promising technique for many issues. It has several successful developments for the interaction with a Digital Mock Up. At last but not least, Section 4 explores how model driven engineering (MDE)1 may provide a systematic approach to create a link between VR solutions and PLM/PDM issues. It proposes a framework where, at a first step, PDM would take benefit from virtual reality. Indeed virtual reality may provide more intuitive and natural interaction with PDM information system. It may be almost a partial solution to pass over some complexity issues.

Apparent complexity of PDM systems

Concepts of Product Data Management

Following Pal&Betz model [START_REF] Pahl | Engineering Design: a Systematic Approach[END_REF] of a product manufacturing company, the product life-cycle has a main sequential stream of activities including "concept creation, creativity", "Embodiement design", "Manufacturing", "Usage and Maintenance", "Disassembly" and "Recycling". This is managed by an overall strategy and must integrate the design of the product life. Let focus on PDM systems. These systems are characteristic of complexity management since they were the first attempt to organize collaboration within a design team, providing space to share information. In the next subsections the main concepts used within PDM systems and the main functions are reminded.

A PDM system mainly provides the following concepts when looking after product definition : An article is the major concept handled by a PDM system. It organises the product structure tree shared by every contributors to design. The tree of articles is referred as the Bill Of Material (BOM). It usually corresponds to an assembly or a single component of the product but some companies also use it as a function tree decomposition.

A document is a logical set of information, to identify a usual computer document (text, spreadsheet, presentation, image, etc.). The PDM document refers one or several computer files and record some meta-data (author, creation date, version, validation state, maturity, etc.). Some documents have special associated attributes or function: CAD models provide a good connection between CAD software and PDM. When the document is uploaded from the CAD software a 3D standard view may be created. A directory is an object where designer can pack several data together. A directory may contain documents or sub-directories as on a usual computer disk, but also articles. Sub-directories create a new hierarchical view of data.

Companies can decide to maintain several hierarchical view of data by sorting them respect to services (CAD service, Simulation, Manufacturing process, etc.), or to business project, or any other organization. Multi-view introduces some complexity within the analysis of the graph of information since several trees provide access to information. A configuration is a set of article versions that identify a specific arrangement of the product. Then in the same data-base several configurations of a same product are managed. The configuration is thus a snapshot of the product definition. Several snapshots can share common parts and identify some items which are different from one configuration to another one. A change Management item is defined to ensure the management of changes. This is a specific process where the company must capitalize problem reports, modification demands, and the management of the change process. These objects obviously refer the previous ones. Indeed a problem may occur on a specific configuration of an article and must lead to a new version of a document.

More complex meta-model could be identified if we enter into project management considerations where team, user, role, forums, authority, organisation, tasks, deliverables, milestones, etc. should be linked to this model: but the product data mainly refers about five core concepts. Figure 1 organises these concepts within a UML diagram to provide a basic vision of their relationships. The previous concepts are tangible for end-users: at this level of analysis, a PDM system should be very simple to use by any individual person with a few professional skill. The 5 previous concepts and their relationships lead indeed to complicate models. An PDM instance is a graph of concepts instances linked by relations compatible with a UML diagram (Figure 1 is such a UML diagram). This graph is rapidly not any more understood by a human brain and appears as really complex to manage. Learning PDM usage remains non natural and practise let experts concentrate on few function to avoid the overall complexity. Next section complete this PDM description with its main functions.

Functions for Product Data Management

The main functions for PDM systems can be listed as follow:

Nantes, France, 6th -10th July 2013 3 Creation of information: these functions allow to create new parts, documents, directories, configurations and change items. Whenever a model is updated, a new version is created through a check-in process. Right Permission Management: Most PDM systems manage the concepts of User, Group or Role which enable data protection but also work-flow management. Depending on its state, (draft, validated, etc) every item can be accessed in read or write mode by specific users or roles. When a data is shared by several users, each one can reserve the modification to himself through the check-out mechanism. Indeed processes to merge concurrent edited version of a same document [START_REF] Sadeghi | Formalization of design rules to assist conflict detection in collaborative design[END_REF] were poorly studied within engineering models. The reservation of data which is released by the check-in mechanism is a way to short-cut the solution. Navigation / Search: A key feature within every PDM system helps to find information. This may be done through navigation or global search mechanisms. Indeed these functions are more complex by the existence of versions and configurations. The multi-view property for every data usually provides search output with a list of documents which looks equivalent but are indeed small variation of the same item. Work-flow : To support work-flow management is also a real advantage of PDM systems. The main work-flow is dedicated to change management. A second one was more lately integrated with project management issues. The work-flow is another multi-view dimension which makes PDM a complex system. Complementary functions: Many other functions are provided by PDM systems but are secondary functions: Document pre-viewer: some specific viewers/editors can be integrated to ease the perception of the document content. Usually CAD geometric models are well supported with pre-visualization of 3D snapshot.The Nantes, France, 6th -10th July 2013 4

end-user has an overview and navigates around the object without edition facility. Connectors: To ease interoperability with expertise tools connectors are proposed with specific software. CAD connectors are the most common practise and offer functions to directly access the PDM CAD documents from the CAD software. Check-in and check-out functions can also be integrated. At last but not least import of CAD models are available to create 3D documents or to identify the Bill of Material which is implicitly defined within the CAD system.

These functions are the main use case that can be applied by the end-user. But indeed the number of options and views that are proposed by PDM system let most end-users confused with the result of their action. Once again as for concept description, the PDM system appear a a complex system.

Virtual reality for PDM

Every activity requires rendering information. Newest visualization technologies are supposed to increase the efficiency of activities. However new visualization technique does not necessarily mean a better efficiency. This article aims to explore the opportunities opened by visualization and interaction for PDM activities.

Definition of Virtual Reality

In [START_REF] Arnaldi | Tité de la réalité virtuelle[END_REF] Virtual Reality is defined as "a technical and scientific domain using computer science and behaviour interfaces for the simulation of 3D artefacts behaviour within a virtual world. The 3D artefacts interact in real time with themselves and one or more users immersed through more or less natural sensorengine chanels". This definition clearly highlights the concepts which are handled through virtual reality. From a systemic point of view, the virtual reality systems is defined by: its internal components: it may be artefacts of the virtual world. The geometric model of artefacts is a key point to identify artefacts of this world. But human user also participate to the virtual reality system. On pure virtual reality, users senses are disconnected from the real world unless mixed or augmented reality is referred. its behaviours model the reaction of artefacts to events coming from the virtual and real world (captured with sensors) and may send feedbacks to the real world through actuators. its functions: virtual reality enables real time interaction. That means that behaviours must be simulated in real-time or pre-simulated. The final user will accept to use virtual reality if it enables to achieve a task on a natural and efficient way.

Nantes, France, 6th -10th July 2013 5

The IFIP WG5.1 10th International Conference -PLM13

To enable Virtual Reality usage for any use case (including PDM) expects to define the artefacts of the virtual world, the users who can be involved, their expected behaviours and a natural and efficient interaction model.

Variety of tools and techniques

Immersion techniques from virtual reality mainly call to mind 3D caves or head mounted devices but indeed the panel of technology is much more wide.

-In 3D caves stereoscopic views are projected on the walls of a room. The views are adapted to the tracked position of a single user. -Head mounted devices provide a similar effect with two separated 2D displays in front of each eye. -Holographic devices create a direct 3D perception (without glasses) which can be mixed with reality. Auto stereoscopic devices should provide the same effect on the user point of view even if technology is different with more limited 3D perception characteristics. -Ultra-High definition (4K and 8K displays) exist in few institutes. However applications could increase more rapidly than immersion technologies. Indeed the installation of a high definition display consume less room than 3D caves.

Standards are incoming and the deployment should be more rapid. Tiled displays is another way to extend the resolution and the size of the surface with respect to traditional displays [5] -At last but not list displays on flexible material are under study and will open new opportunities [START_REF] Crawford | Flexible flat panel displays[END_REF].

Then the combinations of displays solutions make the virtual reality equipments quite complex to classify. Moreover displays are not the unique components participating to a virtual reality environment. It is clear that the perception of immersion depends on the technical environment [START_REF] Wits | Exploring the potential of 3d visualization techniques for usage in collaborative design[END_REF] Indeed the interaction mode is also fundamental. In most virtual cases the observer does not interact directly with virtual objects but through avatars. The avatar is handled by a deported device. The position of this visual avatar locates an indirect connection to a behaviour of the virtual scene. In few cases like with holography, the interaction with object may be direct. [START_REF] Noël | From integrated to intuitive design thanks to new technologies[END_REF] classifies the various interaction devices respect to the following categories: 2D/3D devices: the device is considered as a 3D device whenever it manages the 3D position of an avatar. number of degree of freedom (dof): tactile surfaces are usually plane and thus are 2 dof system even if we can imagine some 2.5 dof systems. Haptic/Passive devices: Haptics provides feedback to the user by several metaphors.

At last some device are a combination of displays and interaction modalities. Multi-touch tables are a good example where a tactile surface is merged with the display surface. This classification may help defining the tangibility of the virtual world [START_REF] Noël | From integrated to intuitive design thanks to new technologies[END_REF].

Nantes, France, 6th -10th July 2013 6

The IFIP WG5.1 10th International Conference -PLM13

Virtual Reality for holistic PDM

A few applications of virtual reality are already used for PDM activities: to navigate in a digital mock-up, to analyse the results of a scientific simulation, to apply ergonomics analysis, to extend collaboration by improving remote presence. This applications are dedicated to design and production but only few research project is reported in the scientific literature with application for a more holistic view. Graf et al. present several concepts to connect VR and PDM by using a software tool to navigate through the product structure using PDM information on VR [START_REF] Graf | A methodology supporting the preparation on 3d-cad data for design reviews in vr[END_REF]. The described concept covers the structure information but also all relevant PDM data and relationships between PDM objects such as articles, documents and projects. Involved designers should not be concerned about the data preparation, the creation of VR scenes in order to use VR. All product structures and part geometries in the two systems should therefore be kept upto-date at any time. To achieve this objective, PDM system has to be a part of a PDM solution which manages all the information, required for the use of VR: it expects new metaphors for PDM.

Ralph H. Stelzer presents a process integration solution in which the VR components can be changed into basic collaboration interface of a Product Lifecycle Management (PLM) environment [START_REF] Stelzer | Virtual reality based engineering collaboration as part of the product lifecycle management[END_REF]. The connection between VR and PLM systems allow the designers to work in several VR sessions simultaneously on a product. Hence, PLM has a vital function to manage the data and to avoid conflicts during the collaboration work. This can be achieved by visualizing any information of the PLM system from a VR session. It is therefore possible to color the VR components as a function on their release status, highlight different structure allocations or view various modification states.

Hayka H. et al. present an integration solution to provide virtual reality applications with required data from heterogeneous environments such as PLM [START_REF] Hayka | Combining heteregenous plm environments with grid computing and virtual reality applications[END_REF]. The solution uses the Gatekeeper, a Java-application that can be accessed through web service interface and communicates with other servers using web services, web protocols or ssh connections. The Gatekeeper collects data from various sources, secures the data provision and transfer and process submitted job in the background. A prototype shows that the Gatekeeper allows an easy usage of the results gathered during VR sessions and a PDM system independent usage of the data preparation methods.

Kim S. et al present MEMPHIS or Middleware for Exchanging Machinery and Product Data in Highly Immersive Systems to centralize the communication between the CAD and the VR systems via a PDM system [START_REF] Kim | Middleware-based integration of multiple cad and pdm systems into virtual reality environment[END_REF]. MEMPHIS main objective is to overcome the conversion issues between the CAD and the VR systems by managing the meta data of a product and other VR related property data through Meta Data Server. The VR data, which is needed to present 3D models of future products in real time and high quality, can be produced directly from PDM systems. Thus, it reduces the repeated correction integration process between the PLM data to VR data. ManuVAR is a project that develops a prototype combining PLM, virtual reality (VR) and augmented reality (AR) Nantes, France, 6th -10th July 2013 7 and human factors (HF) methods [START_REF] Vink | Manuvar: a framework for improving manual work through virtual and augmented reality[END_REF]. It intends to integrate PLM and VR in a single environment.

All these studies expect a structured method to enable communication between PDM and VR. They emphasize the difficulty to manage this interoperability issue. Here it is also noted that immersion of virtual reality is mainly provided through the real perception of a third dimension not fully availale with traditional 2D displays. Then the main interest of virtual reality for PLM should be to use this third dimension to simplify the understanding of a complex set of information. [START_REF] Shneiderman | Readings in information visualization: using vision to think[END_REF] defines visualization as the use of interactive and computerized visual representations of abstract data to improve cognition. The final user is the main purpose of visualization to help him managing complex set of information.

In [START_REF] Bihanic | Visualisation de systèmes d'information complexes. une approche par « points de vue étendus[END_REF] authors analyse directions and metaphors to simplify complexity analyses through visualization. It proposes a model driven engineering framework to support the automatic creation of extended views in a VSML (Visualization System Modelling Language). It would provide adapted metaphors depending on the user role but also on the device and focus interest. Three main views are identified:

A tree is a hierarchical representation. On an object oriented point of view, a tree is standardized with the defintion of its root handle and for every item a method returning its childs. Each node and tree arc should be associated with attribute values that can be transformed into either, shapes, colors or pixmaps, or size, position or orientation. A map is a reticular representation. A polyhedron visualizing a 3D shape is indeed a specific reticular representation, but every graph are included here. A paysage , as data-scapes or data-mountains, localise information on a given surface. It expects the definition of the surface and the definition at specific location of highlited issues. A combination of previous items : every visualization item can be locally decomposed into a smaller metaphor: it enable to combine metaphors together. It can be also processed by a distribution over a tiled environment.

On a formal way every metaphor is parametrized by a finite set of parameters.

To translate a data model into these metaphors should be driven by a limited set of mechanisms. Next section proposes the base of such mechanisms and thus enables 3D perception of PLM activities. The related mechanism based on Model Driven Engineering techniques will provide transformations as described in [START_REF] Bihanic | Visualisation de systèmes d'information complexes. une approche par « points de vue étendus[END_REF] and will enable the [START_REF] Bihanic | Visualisation de systèmes d'information complexes. une approche par « points de vue étendus[END_REF] proposal by providing effective mechanisms.

Transformation of PDM information into Visualization

Principle

Let suppose that we have a PDM model. Then a set of transformation rules must be defined to create potential visual metaphors and to distribute these metaphors other a set of renderers. The transformation must also identify behaviours and Nantes, France, 6th -10th July 2013 8 will lead to interactive Virtual Reality framework. This principle has been implemented through autonomous agents. Agents communicate by sharing events on the common model of Figure 2. As stated by this UML diagram, the visualization environment is defined by a set of renderers. These renderers can be distributed on a network by identifying the host computer and their location within the computer rendered area. Every renderer is in charge to display a metaphor. The visualization environment also controls rules in charge to manage events coming from interaction with the renderer or from the visualized information system.

To ensure the link with external applications we use an application connector which is in charge to survey in real-time the events produced by the application: here the PDM Model. This connector must implement the following API:

1. GetRootHandle() → [ID]: this method must return a list of unique identificators of the application items. These "root" items will play the roles of the main handles on the model issued from the application point of view. For PDM this connector method should return for example a list of the main configurations. Thus user accesses a configuration of the product potentally decomposed into several alternative configurations. Each configuration provide access to product items, but indeed this can be adapted to special requirements depending on the PDM meta-model. With this API the system read from and write to any application model. It enables to connect a PDM system and to visualize everything through various metaphors. The number of events in a PDM system are important since every collaborator should edit his work whenever expected. But indeed there is no streams of modifications that need rapid updates of the visualization scene. A check-in is done once and expects a check-out almost a few second later but not at every millisecond. That means that the visualization metaphors should support a Virtual Reality environment (no real-time issue). Mainly navigation is expected.

This API provides a generic way to navigate within both :

the meta-model level since the API provides information about the classifier, their attributes and relations (including inheritance). the model level since it provides access to items, item attributes, and relations. The SetItemAttribute, InsertItem and DeleteItem functions allow edition of the model.

Nantes, France, 6th -10th July 2013 10

By managing the meta-model and the model level, this API opens access to a Model Driven Engineering approach as discussed in the next section. applied for the transformation of a Platform Independent Model (PIM) into a Platform Specific Model (PSM). This paper refers to horizontal translation and synchronization rules. The rules are defined at the abstract meta-model level and should be executed at the model level. The translation concerns two different meta-models: here from the PDM meta-model to the visualization meta-model. A major challenge for visualization in Virtual reality is to apply this translations in real-time. Then to complete the interconnection between PDM and visualization, transformation rules must be implemented. Some rules are implicit as synchronization of attributes values or relationships between items whenever the visualization expect an edition or whenever the PDM system is edited, but more complex rules require a specific development. Especially the choice of metaphors must be identified and properly linked. The rules have also the ability to define behaviour of the virtual scene since rules can react to basic events (OnSelect, OnUnSelect or OnMove). Moreover the connector system can be extended to connect other applications in charge of simulating some behaviours (Mechanical effects as contact, etc within the scene).

To fix ideas an example of set of rules could be used: assuming that a 3D digital mock-up is available connected with the bill of material.

1. At initialization a list of product is visualized. 2. When a product is selected its digital mock-up is visualized as a usual 3D model. 3. When a part is selected, the list of documents must appear through specific 3D representations. 4. When a document is selected, the list of versions should appear on the line normal to the surface selected point. 5. When a version is moved towards a basket 3D model, the version must be deleted. 6. etc. A prototype environment (named "CVE") has been developed for experimentation. The system acts through autonomous agent. Every renderer or device has its own autonomy. Connected agents can be of various type: management of interactive devices (tracking system) are also developped through specific agents. This environment enables to test various metaphors for any applications (including a PDM or other PLM application). Figure 3 shows the CVE editor which supports the configuration of the visualization environment. CVE demonstrates the powerness of the system and its capacity to project any application in various visualization metaphors on distributed renderers. Events, connector to the PDM system and graphic rendering are created directly through this editor.

At the meta-model level, transformation rules can be written by the VR tool developpers in a scripted language (in CVE currently python is used). But it can be also added directly by end-users through a basic scripting language accessing the models and the meta-models through the API of the previous section. This will ensure the creation of metaphors adapted to the real expected usage of endusers. The editor of Figure 3 The IFIP WG5.1 10th International Conference -PLM13 a demonstration that visualisation rules could be defined by end-users with very few scripting capacity.

At the model level, when a new product is created in the PDM system (creation of an article at the highest level), a 'OnInsert' rule is called. This rule adds an object in the related visualization renderer but also defines the type of metaphor which must be used to visualize the PDM item. When the metaphor is selected in this renderer a 'OnSelect' rule is called: it invokes a new metaphor to display a focus on the product. This metaphor may replace the current view or be projected on any other renderer.

This environment demonstrates the capacity of Model Driven Engineering to support creation of metaphors for PDM activities enabling experimentation of new way to interact with PDM systems.

Conclusion

By organising visualisation as a systematic approach with a set of predefined metaphors, this paper opens new directions to visualize complex information set. It may support simplification of some views by creating unusual metaphors. 3D may be used to project things which were not thought as 3D and must not be reserved to 3D geometry visualization. The paper uses a core view of a PDM system; it proposes via a generic framework the PDM model visualization based on Model Driven Engineering transformations.

The capacity to use transformations towards Virtual Reality environments depends on the capacity of the transformations to be applied in real-time or to be prepared offline. The extension of mechanisms with interaction facility ensures a potential natural way to navigate within a virtual PDM view. The metaphors and related behaviours will have to be assessed in the context of PDM applications: the main issue is to compare intuitiveness and tangibility of every metaphor. It should lead to new metaphors for a better understanding and management of the apparent PDM complexity.

Fig. 1 .

 1 Fig. 1. A UML class diagram description of the main PDM concepts.

Fig. 2 .

 2 Fig. 2. Abstract description of the Visualization environment

2 . 9 '

 29 GetItemClassifier(ID) → CID : returns an identifier of the type of item identified by ID. For a specific ID the system should returns either 'Article', Nantes, France, 6th -10th July 2013 Configuration', 'Changed Demand', 'Problem Report', 'Document', 'Directory' or 'CAD Model'. 3. GetClassifierAttributes(CID cl) → [(name,type='Real'|'Integer'|'Boolean'|'String'])]: a specific item associated with the classifier CID has a list of attributes identified by their name and their type. This method returns the list of attributes for a given classifier. For every classifier a list of attributes must be associated. For an article or document the state 'Draft', 'Proposal', 'Validated' is one of these attributes. The cost could be a second one. The right permission as 'checked in' or 'checked out' should be another one, etc. 4. GetClassifierRelations(CID cl) → [(name,card_{min},card_{max},RCID)]: a specific item associated with the classifier CID has a list of relations with other classifiers. This method returns the list of tuples identifying the relations to a given RCID classifier. The relation is named and has a minimal and maximal cardinality. In the PDM case, as for attributes, every classifier has relations which are clearly identified for the PDM model on the class diagram 1. An article will have the 'IsDefined' relation associated to the classifier 'Document'. 5. Inherits(CID cl1,CID cl2) → boolean : This method return True if cl1 inherits from cl2. For PDM,the class diagram 1 identifies inheritance relationships: the 'CAD Model' inherits the 'Document' class, etc. 6. GetItemAttribute(ID,attribute) → Real|Integer|Boolean|String: This method return the value of an attribute from a given item. 7. SetItemAttribute(ID,attribute,value) : This method edits the value of an attribute from a given item. 8. GetItemRelation(ID,relation) → [ID] : This method returns the list of IDs from a relation of a given item. 9. InsertItem(ID,relation,IID) : This method inserts a new item into a relation of a given item. 10. DeleteItem(ID,relation,DID) : This method removes an item from a relation of a given item.

Fig. 3 .Editor 4 . 2

 342 Fig. 3. Visualization Editor

  also supports interactive description of rules. It is Nantes, France, 6th -10th July 2013 12

The paper uses the horizontal translation of MDE theory and does not practise vertical translation of Model Driven Approach (MDA) (translation from PIM to PSM)Nantes, France, 6th -10th July

[START_REF] Pahl | Engineering Design: a Systematic Approach[END_REF]

Nantes, France, 6th -10th July 2013 14

Acknowledgments. This paper was written within the scope of the VISION-AIR infrastructure project. VISIONAIR is leaded by Grenoble INP, 46 avenue Felix Viallet, F-38 031 Grenoble cedex 1, FRANCE. This project is funded by the European Commission under grant agreement 262044.


Christian Emmer

Arnulf Fröhlich

Josip Stjepandic
email: josip.stjepandic@opendesc.com

Advanced Engineering Visualization with Standardized 3D Formats

Keywords: Engineering Visualization, Interoperability, Data Exchange, JT Standard, Supply Chain, Engineering Collaboration

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Although the CAD translation technology has gathered a high level of maturity and robustness, there is still a strong need for further development driven by crucial business processes like digital mock-up (DMU) which is established as core validation process in the past years. Furthermore, the CAD models have already reached a level at which where they are easy to use, despite a high level of complexity behind that. Meanwhile, various 3D visualization formats have entered the market on the broad front by combining the high information content with easy handling and excellent performance. Thus, these formats can support many process chains from styling to product simulation, validation and production as well as downstream life cycle phases. By the extensive penetration of visualization formats in the market the old discussion was reopened, whether the unique format can fulfill the requirements of the engineering collaboration (internal and external). Finally, the users need the recommendation too, which format meets their needs in the best way [START_REF] Stjepandic | Digital Engineering Visualization, SASIG, SASIG Guideline[END_REF], [START_REF]Collaborative Product Visualisation -General issues and use case description[END_REF]. Typical use cases for functional evaluation of such formats are the viewing of engineering data, the design in context, the data exchange between partners in the supply chain, the packaging and digital mock-up (DMU), the documentation and archiving, and use in the portable PLM document, i.e. use of 3D and additional information in domains related to engineering (Figure 1). After the rough evaluation of the technical specification of the visualization formats an overall comparison can be drawn [START_REF] Fröhlich | White Paper 3D Formats in the Field of Engineering -a Comparison[END_REF] (Figure 2).

Fig. 2. Comparison of four visualization formats [3].

However, in the automotive and aerospace industry JT from Siemens PLM is currently under heavy investigation to apply it in downstream processes, after it was established as a leading format for the engineering visualization in many global companies [START_REF] Biahmou | Universelle Formate für Visualisierung und Konvertierung in der Engineering-Kollaboration[END_REF]. For instance, there is the demand to exchange exact geometry, product data information and additional attributes. Moreover JT is also a potential data format for long-term data retention. Consequently, there is high user interest in quality and robustness of the applications, the interfaces in particular. Thus, the further explanation in this paper will be focused on JT, although other formats (STEP, 3DPDF, 3DXML) are in the different stages of standardization procedure.

Open standards enable reduction of total costs of ownership and ensure independence from specific vendors and competition. With regard to visualization data exchange there is a strong support to use JT and STEP AP 242 (ISO 10303-242) as complementing standards for lightweight visualization format for 3D industrial data as well as for product structure, meta, and kinematic data [START_REF] Handschuh | Wertextrahierende Nutzung von offenen leichtgewichtigen Datenformaten in automobilen Kollaborations-und Entwicklungsprozessketten[END_REF].

The publication of the JT specification as an ISO Publicly Available Specification (PAS 14306) laid the foundation for establishing JT as a binding process format. The ProSTEP iViP Association and the VDA (German Association of the Automotive Industry) subsequently launched three coordinated JT-specific projects: the JT Workflow Forum, the JT Implementor Forum and the JT Application Benchmark.

Technical Background and Standardization

JT is a binary format whose data model supports various representations of CAD geometry. The representations can be stored in a JT file individually or together [START_REF] Handschuh | Wertextrahierende Nutzung von offenen leichtgewichtigen Datenformaten in automobilen Kollaborations-und Entwicklungsprozessketten[END_REF] [6].

• BREP (Boundary Representation): Offers the highest level of representational precision. BREP data is compressed using different algorithms and stored without loss. In the current specification 9.5, two BREP representations are permitted: the traditional JT-BREP representation and XT-BREP, which is based on the Parasolid boundary representation and will be preferred in the further implementation of JT based software. • Tessellated Geometry: A faceted representation of solids and surfaces. Different levels of detail (LOD) can be defined within a JT file. A low LOD means a lower level of precision but a smaller volume of data, while a very high LOD means an almost exact geometry but a large volume of data. • ULP (Ultra-Lightweight Precise): The latest compression method is ULP. The ULP format enables a lightweight, semi-precise representation of the 3D geometry. The level of precision that ULP offers is significantly higher than for tessellated geometry while the file size is significantly smaller. The primary focus lies on providing high quality surface geometry that exhibits only minor deviations from the original BREP geometry. JT version 8.1 has been initially published by the ISO as a publicly available specification (ISO PAS 14306). The ISO standardization process has been finished by endorsing the ISO standard (ISO 14306) in December 2012 for the recently published JT version 9.5, which has been expanded to include the specification for ULP and semantic product manufacturing information (PMI, product metadata) among other things.

Generating data in a neutral 3D format results in most use cases with a significant reduction in volume. In order to compare the file size of the 3D formats, fifteen test assemblies from different CAD systems were used to generate different 3D formats [START_REF] Handschuh | ProSTEP Symposium 2012: JT on the Path of Enlightenment -Report of the JT working groups[END_REF]. As a result, the volume of data is determined more by data content then by the format itself.

The volume of exact BREP data after conversion to JT is approximately the same as after conversion to 3D PDF. The same applies to tessellated content, where the result for both formats is about the same as for 3D XML. In the case of simplified BREP data, the volume of data for both JT and 3D PDF are approximately the same. In the case of STEP data, use of an external compression algorithm achieves a marked reduction in size. As a consequence, higher accuracy requires more storage space as a general rule.

Use Cases

An evaluation of the 22 use cases defined by automotive manufacturers and their suppliers indicated a particularly high priority for four use cases, which are presented below in more detail by way of example [START_REF] Handschuh | ProSTEP Symposium 2012: JT on the Path of Enlightenment -Report of the JT working groups[END_REF] (Figure 3). Fig. 3. Use cases for simplified formats [START_REF] Handschuh | ProSTEP Symposium 2012: JT on the Path of Enlightenment -Report of the JT working groups[END_REF].

Viewing: If the use of a CAD system is not desired, the visualization of engineering data using 3D viewers comes into play in a number of different situations: the presentation of product data, the representation of 3D models for information purposes (e.g. for a design review or marketing) and the realistic representation in virtual reality systems.

The use case can vary according to the concrete application context involved. While the simple viewing of the geometry is sufficient in many cases, in other cases metadata or high-performance viewing of huge assemblies plays a key role. The most important requirements are:

• Quality criteria for geometry accuracy must be fulfilled.

• Different level of details must be available.

• Detailed color information must be available for entire part and single geometrical features.

• Metadata like attributes must be stored.

Packaging / DMU: In digital mock-up (DMU), the spatial properties of a product are examined and checked. This can involve checking the overall geometry with regard to dimensions and shape, interference checks, collision checks for assembly and disassembly, as well as design space checks (Figure 4).

For these purposes, the geometry, product structure and metadata are displayed and analyzed in a DMU application. The result of the DMU analysis is subsequently summarized and documented in a report. The most important requirements are:

• Use of models from different source systems (multi-CAD).

• High-quality examination of large assemblies.

• Transferability of kinematics from the original model to the target model for dynamic DMU analysis.

Design in Context:

A typically used modeling method is the design in the context of the existing geometry. In that case existing CAD models (e.g. from previous design or from partners) are loaded into the CAD system. The design engineer then references new or existing JT-geometry to the loaded parts or assemblies. References from native CAD to JT are also in focus. These references can be between auxiliary geometry (point, axis, plane), geometrical elements such as edges, vertices or faces and exact geometrical references like curves. In the subsequent downstream processes it is required to use this assembled model as a merged single unit. Hence, the creation of technical drawings must be possible. The most important requirements are:

• Tessellated as well as exact B-Rep data must be stored.

• Links between JT and native data must be possible.

• Technical drawings must be derivable from hybrid models.

Partner Integration: The use case is divided into two sub-sections. The aim of the "OEM to Supplier" use case is to send validated JT geometry with all necessary metadata to the supplier, whereas the "Supplier to OEM" use case defines the exchange of JT files to the OEM. Common to both sections is that the use cases provide a basis for further use cases. This means that by the Supplier or the OEM more specific use cases (viewing, design in context, etc.) will be applied subsequently. The most important requirements are:

• Quality check of JT and validation against native CAD model.

• Meta data must be contained in JT model.

• Removal of intellectual property (if necessary).

Evaluation and Testing

An important aspect in driving the application and development of JT is a coordinated approach between the different bodies on the one hand and a coordinated approach of the activities themselves on the other hand.

Involved Bodies

Basis for the standardization activities of JT were the enormous efforts of many international bodies. After the initial impact had been accomplished by SASIG [START_REF] Stjepandic | Digital Engineering Visualization, SASIG, SASIG Guideline[END_REF], the four bodies: ProSTEP iViP Association (PSI), the German Association of the Automotive Industry (VDA), the Automotive CIO´s and the Global Automotive Advisory Group for PLM (GAAG) have played a leading role (Figure 5). Therewith ProSTEP iViP (www.prostep.org) has thoroughly pursued these activities.

Fig. 5. International cooperation in the standardization of JT

Last but not least, the MoU (Memorandum of Understanding) between Siemens PLM und ProSTEP iViP provides the basis between both parties in the area of JT, in order to foster a common understanding of goals and measures to establish JT as a binding process format.

National and International Coordination

In 2009 the ProSTEP iViP Association, in a joint effort with the VDA (German Automotive Association), has started three different but interacting world-wide unique JT activities. Within the so-called JT Workflow Forum, Use Cases for the application of JT are specified, describing the common view from industry. The JT Implementor Forum provides support in JT translator development and maintains a platform for interoperability testing for the vendors. Within the JT Application Benchmark the requirements are comprehensively tested within neutral environment.

The project plans of these three project groups are well-harmonized, for driving the application of JT as a common effort. JT Workflow Forum: Aim of the project is to define and prioritize key use cases and to identify relevant downstream processes for the JT based data exchange. For all use cases, requirements are collected and test criteria defined, e.g. under the aspects of exchanging of visualization data, the validation of 3D geometry, GD&T (Geometric Dimensions and Tolerances) and -last but not least -translator quality.

These tasks are supported by the Content Harmonization subgroup, which is responsible for providing a clear definition of which requirements should be satisfied by the JT format and which by STEP AP242 as backbone format. JT Implementor Forum: Within the framework of the JT Implementor Forum Project Group, a platform for interoperability testing for the vendors is maintained. It is a forum where participating vendors can test the translators that they are developing "behind closed doors". The JT Implementor Forum is a neutral forum for software vendors, where they can perform tests in an atmosphere of mutual trust and exchange information on experience already gained.

In addition, from the vendor perspective, the activities within the JT Implementor Forum can be seen as a kind of preparation for the JT Application Benchmark. JT Application Benchmark: Based on the recent standardization activities of JT and also STEP AP 242, it is of importance to assure data exchange quality within a neutral Benchmark and to provide support in JT translator development.

The ProSTEP iViP Association, together with the VDA PLM working group, has initiated a first JT translator benchmark in 2009. Subsequently, the second translator benchmark was conducted in 2010. The third benchmark was completed by the end of 2012. Thereby the focus will be laid on three main topics:

1. CAD to JT export, focus on LOD and PMI 2. JT viewing, focus on performance and functionality 3. Assembly conversion with STEP AP 242 XML and JT Vendors participating in the benchmark are invited to present their latest functionalities in form of Showcases to the JT Workflow Forum members. In focus are cutting-edge solutions that demonstrate the possibilities of the JT format and applications. There are still small functional errors and therefore a need for improvement (Figure 6).

Pilot Projects

As a further step towards the productive usage of JT in automotive downstream processes, first pilot projects are established. Volkswagen decided to use JT for internal downstream processes to eliminate the need for drawings [START_REF] Handschuh | ProSTEP Symposium 2012: JT on the Path of Enlightenment -Report of the JT working groups[END_REF] [8] (Figure 7). This application is limited to the use case "single parts" and shall be subsequently extended to the full assemblies to avoid the usage of huge JT monolithic files.

Fig. 7. Usage of JT within the Volkswagen Group

One of the most challenging project is the Daimler/Continental JT pilot project by exchanging an ESP Electronic Control Unit.

In the following the process landscape (Use Case: "Supplier to OEM") of the Daimler/Continental JT-pilot project is shown (Figure 8).

In order to fulfill the OEM needs (e. g. in case of data quality) it has to be ensured that the JT and the accompanying structure formats are created properly. In a first step the configuration settings of the JT-translator have to be adjusted to the OEM needs. Therefore, the mentioned ProSTEP iViP JT Content Harmonization workgroup (JTCH) has created a first best practice document [START_REF] Prostep Ivip | Whitepaper Applying JT -Guidance for Using JT in Practice Version 2[END_REF]. In the second step, the OEM specific data preparation has to be done. Therefore the Daimler JT Supplier Package (JTSP) is available for all Daimler suppliers [START_REF] Handschuh | ProSTEP Symposium 2012: JT on the Path of Enlightenment -Report of the JT working groups[END_REF]. Fig. 8. Usage of JT in partner integration [START_REF] Handschuh | ProSTEP Symposium 2012: JT on the Path of Enlightenment -Report of the JT working groups[END_REF] The Daimler JTSP offers the opportunity to edit the JT internal attributes and to prepare XML based structure formats to meet the OEM requirements. The third step in the process landscape is the data exchange to the OEM. In case of the Daimler AG the OFTP based SWAN system is used.

The final step of this process is the data import into the Daimler PDM system Smaragd. At this point in time the externally created JT datasets are released and available to all Daimler downstream processes such as Viewing, DMU or Design in Context [START_REF] Handschuh | Standardized formats for visualizationapplication and development of JT[END_REF].

Meanwhile the full CAD data exchange by using JT is going to be adopted as a base CAD translation technology by supplier portals like OpenDESC.com (www.opendesc.com) [START_REF] Bondar | Globalized OEM and Tier-1 Processes at SKF[END_REF].

Conclusions and Outlook

This contribution addresses the state of the art activities in order to establish JT as a universal process format. Industry needs simple solutions for the efficient use of IT technology, including consistency in processes. There are strong requirements for lightweight 3D formats for the visualization and downstream processes, complementary formats in order to exchange meta data, structure data and kinematics data as well as open and standardized formats to reduce total cost of ownership and to minimize dependency of single vendors [START_REF] Röhl | Einsatz des JT-Formates in der Digitalen Fabrik[END_REF], [START_REF] Prostep Ivip | Whitepaper Applying JT -Guidance for Using JT in Practice Version 2[END_REF], [START_REF] Handschuh | Standardized formats for visualizationapplication and development of JT[END_REF]. After these very promising pilot projects mentioned above, the activities on the subject of lightweight visualization based on JT have already reached a good level of maturity, encouraging the wide range of companies and users, whereas it is a forthcoming task to push the integration with the accompanying format STEP AP242 (Figure 9). Although first applications creating or using STEP AP242 XML as an outor input format are already available today, the wide usage will be announced in the next years. The future data exchange process will adopt JT as well as STEP AP242, ensuring the exchange of whole complex products at all stages of product and process development (Figure 10).

Fig. 1 .

 1 Fig. 1. Typical use cases of JT [1].

Fig. 4 .

 4 Fig. 4. Use case diagram "Packaging"

Fig. 6 .

 6 Fig. 6. Results of recent JT benchmark

Fig. 9 .

 9 Fig. 9. The schedule of JT and STEP AP 242

Fig. 10 .

 10 Fig. 10. Assembly data exchange with JT and STEP AP 242