• No results found

A Step Implementation For Product Structure Data Exchange

N/A
N/A
Protected

Academic year: 2021

Share "A Step Implementation For Product Structure Data Exchange"

Copied!
73
0
0

Loading.... (view fulltext now)

Full text

(1)

Institutionen för datavetenskap

Department of Computer and Information Science

Final thesis

A Step Implementation For Product Structure

Data Exchange

by

Jingjing Qian

LIU-IDA/LITH-EX-A--12/016--SE

2012-04-16

Linköpings universitet

SE-581 83 Linköping, Sweden

Linköpings universitet

581 83 Linköping

(2)

Final thesis

A Step Implementation For Product Structure Data Exchange

by

Jingjing Qian

LIU-IDA/LITH-EX-A--12/016--SE

2012-04-16

Supervisor: Nordgren Andreas, Scania AB

Erik Berglund, Linköping University

Examiner: Arne Jönsson, Linköping University

(3)

Copyright

The publishers will keep this document online on the Internet - or its possible

replacement - for a considerable time from the date of publication barring

exceptional circumstances.

The online availability of the document implies a permanent permission for

anyone to read, to download, to print out single copies for your own use and to

use it unchanged for any non-commercial research and educational purpose.

Subsequent transfers of copyright cannot revoke this permission. All other uses

of the document are conditional on the consent of the copyright owner. The

publisher has taken technical and administrative measures to assure authenticity,

security and accessibility.

According to intellectual property law the author has the right to be

mentioned when his/her work is accessed as described above and to be protected

against infringement.

For additional information about the Linköping University Electronic Press

and its procedures for publication and for assurance of document integrity,

please refer to its WWW home page:

http://www.ep.liu.se/

(4)

ABSTRACT

Scania is a Swedish automotive manufacturer for heavy vehicles and engines. It also offers transport solutions and long term commitment for customers. In today´s Scania, a modular system provides a huge variety of specifications to meet varying dramatic needs for different customers. In order to be able to meet the diverse requirements of customers, modular approach with the support of reusable components is used to increase the efficiency of designing different products.

To customize both product development and product design, computer aided design(CAD) is used to support the process of design and design documen-tation. ¨CATIA¨ is a multi-platform CAD software and ¨ENOVIA¨ is a product modeling product offers product database management for virtual model design into CATIA, both ¨CATIA¨ and ¨ENOVIA¨ are developed by the French company Dassault Syst`emes are chosen by Scania to support its product development.

The modular system approach requires the system support for product struc-ture, which is managed by a mainframe called SPECTRA.

The thesis project is mainly about system designing a new module which takes the responsibility for exchanging information between SPECTRA and ENOVIA. In more detail, the new component is to perform a mapping of data in SPECTRA format into a format which ENOVIA can import. The mapping module has several interfaces with other applications in the system. JavaMigrator provides the environment to import data from the mainframe and transfer the data into the module and finally output the expected data format into ENOVIA.

To achieve this purpose, several possible solutions were proposed and several methods were tried. Since an in-house developed CAA-module is highly preferred by Scania, the new mapping component will finally be designed into two separate modules, the first part converts the XML extracted from SPECTRA into an intermediate format and the second part is designed to convert the intermediate file into the expected target file.

The intermediate file is required, since the format is independent of changes i

(5)

in both SPECTRA and ENOVIA. Furthermore, it is flexible and less com-plex to maintain than direct mapping from exported XML to ENOVIA. The report focuses on five parts, background, project specification, method-ology, implementation, result and future work.

(6)

PREFACE

This master thesis report was written at Scania CV AB in S¨odert¨alje. This thesis project constitutes the last part of my education in the Master of Computer Systems program at Link¨oping University, Sweden.

The project started on November 1st 2011 and ended on March 15st 2012. The project was full of challenges and a lot of new knowledge was required. Modeling languages like EXPRESS, SDAI(Standard Data Access Interface), Application modules CAA were used in the project. Everything was new and that made the project highly attractive to me.

Before entering into the development phase, I started to study the back-ground information first. Scania provides very open information data base which makes it easy to get started. Necessary background information in-cludes the software architecture, software development process, development environment, and application requirement. During the whole project period I was greatly inspired by the Scania spirit, which is ¨Do the right things¨ and ¨Do the things right¨. That made the development efficient and the quality of the product guaranteed. This report is about the introduction of the project, including the background information, module design, module functionality, methodology and the subsequent performance.

This thesis has provided me with a lot of challenges and I feel that I have learned a lot from them. Working at Scania has given me a broader and more complete picture of what it is like to work as an engineer at a large multina-tional company. At every obstacle I have been encouraged and helped out by my colleagues.

(7)

ACKNOWLEDGEMENTS

First, I would like to thank the ILES group in Scania, who gave me the opportunity to finish my degree project with you. It was very instructive to get a deep insight into your team and your company. I also want to thank all of you who have taken time to help me acquire the information and knowledge related to the project, as well as the material to finish our project.

Especially I must offer my heartfelt thanks to my supervisor Andreas Nord-gren, team manager Cid Rodrigo, and my thesis job partner Sairam Ghanta in Scania. I would also like to thank my supervisor Erik Berglund and my examiner Arne J¨onsson at Link¨oping University. Thank you for your generous help.

(8)

ACRONYMS

AIX - UNIX OS dialect

CATIA - CAD-system by Dassault Syst`emes

CAA - Component Application Architecture (C++ API) CAD - Computer Aided Design

Control-M - Job Scheduler DS - Dassault Syst`emes

ECCO - Toolkit by PDTech, handles STEP

ENOVIA - PDM system can be combined with any CAD-system ENOVDatax - ENOVIA’s native EXPRESS schema

EXPRESS - Modeling language EXPRESS-X - Mapping language

EXPRESS-C - Object-oriented, compatible extension of ISO EXPRESS JM - JavaMigrator, A Scania developed batch job manager

MQ - Message Queue

SDAI - Standard Data Access Interface is an API for EXPRESS defined data

SIAM IP - Scania integration platform

SPECTRA - Scania’s mainframe system for product structure STEP - International standard for product data exchange PDM - Product Data Management

PLM - Product Lifecycle Management UML - Unified Modeling Language XML - extensible Markup Language

(9)
(10)

Contents

1 Introduction 1 1.1 Problem Specification . . . 1 1.2 Project Target . . . 2 1.3 Target Audience . . . 2 1.4 Project Contribution . . . 2 1.5 Report Introduction . . . 2 1.6 About Scania . . . 3 2 Background Information 4 2.1 Product Structure . . . 5

2.1.1 Product structure concept . . . 5

2.1.2 Breakdown . . . 6 2.2 System Components . . . 6 2.2.1 SPECTRA . . . 6 2.2.2 CATIA . . . 7 2.2.3 ENOVIA . . . 8 2.2.4 SIAM IP MQ . . . 9 2.2.5 JAVA Migrator . . . 10 2.2.6 ECCO . . . 11 2.2.7 Control-M . . . 11 2.3 System Architecture . . . 12

2.4 STEP standard and ECCO . . . 14

2.4.1 STEP standard . . . 14 2.4.2 STEP file . . . 14 2.4.2.1 EXPRESS . . . 14 2.4.2.2 Step file . . . 16 2.4.2.3 SDAI . . . 16 2.4.2.4 EXPRESS-X . . . 16 2.4.2.5 EXPRESS-G . . . 20 2.4.2.6 EXPRESS-C . . . 21

2.4.2.7 Relationship between different parts in STEP 23 2.4.3 ECCO Toolkit . . . 24

2.4.3.1 ECCO functionality . . . 24

(11)

CONTENTS

2.4.3.2 ECCO compiler . . . 25

2.4.3.3 ECCO API . . . 26

2.4.3.4 ECCO data adapter . . . 26

2.5 Development Environment . . . 27 2.5.1 CAA/C++ . . . 27 2.5.2 SDAI . . . 29 2.5.3 JAVA/JSDAI . . . 31 2.5.3.1 JAVA . . . 31 2.5.3.2 JSDAI . . . 31

3 Project Specification and Goal 33 3.1 Project Specification . . . 33

3.2 Project Goal . . . 34

4 Module design and methodology 37 4.1 Design flow, methodology . . . 37

5 Implementation 40 5.1 Proposed Solution 1 and implementation . . . 40

5.1.1 Proposed solution 1: CAA + CAA . . . 40

5.1.2 Implementation . . . 41

5.1.2.1 HASHTABLE functionality obstacle in CAA 42 5.1.2.2 Source file importing obstacle in CAA . . . 42

5.1.2.3 Mapping language obstacle in CAA . . . 42

5.2 Proposed Solution 2 and implementation . . . 43

5.2.1 Proposed solution 2: JAVA + CAA . . . 43

5.2.1.1 JAVA module . . . 44

5.2.1.1.1 Java programming language . . . . 44

5.2.1.1.2 New Scania schema . . . 45

5.2.1.2 CAA module . . . 47

5.3 Proposed Solution 3 and implementation . . . 48

5.3.1 Proposed solution3: CAA + CAA . . . 48

5.3.1.1 CAA module in first part . . . 50

5.3.1.2 CAA module in the second part . . . 50

6 Conclusion and Future Work 53 A UML Files 56 A.1 JAVA+CAA Module . . . 56

A.1.1 Class Diagram . . . 57

A.1.2 Sequence Diagram . . . 58

A.2 CAA+CAA Module . . . 60

A.2.1 Class Diagram . . . 60

(12)

Chapter 1

Introduction

1.1

Problem Specification

Scania is a Swedish automotive manufacturer for heavy vehicles and engines. To be able to customize both product development and product design, com-puter aided design(CAD) is used to support the process of design. CATIA is a multi-platform CAD software, ENOVIA is a product modeling product to offer product database management for virtual model design into CA-TIA. Both of them are developed by a French company, Dassault Syst`emes. Scania has customized CATIA and ENOVIA to support its product devel-opment activities.

In order to be able to meet the diverse requirements of customers, mod-ular approach with the support of reusable components is used in Scania to increase the efficiency of designing different products. The modular sys-tem approach requires the syssys-tem support for product structure, which is managed by a mainframe called SPECTRA.

When a CATIA user orders a product structure in SPECTRA, the data would be generated from SPECTRA and transferred to ENOVIA in a spe-cific format which ENOVIA recognizes and then ENOVIA transfers the data back to CATIA.

The functionality of the data mapping from the data generated from SPEC-TRA to a specific data format which ENOVIA can import is performed by a middleware component called ECCO in the current system. But ECCO is aimed to be replaced by a new module.

There are two main reasons to replace ECCO. The first reason is ECCO no longer supports the version of AIX in use on Scania´s development and production servers. This is a serious risk and a major obstacle every time

(13)

1.2. PROJECT TARGET

when the mapping is needed to be rebuilt. The second reason is ECCO requires highly specialized knowledge in order to make changes. It is dif-ficult to keep this knowledge in the development team, and therefore an in-house developed CAA-module(C++ API) or other standard module is highly preferred.

1.2

Project Target

The project shall:

a.) Present a study of the current implementation of STEP(an ISO standard which will be introduced in section 2.4) using ECCO.

b.) Develop a CAA-module or other standard module.

c.) Show whether it is feasible to replace the ECCO component.

1.3

Target Audience

This report is aimed for readers with basic knowledge of computer program-ming, more specifically those with knowledge of C++ and JAVA.

1.4

Project Contribution

This thesis project has involved two students, me and Sairam Ghanta, a student at Mid Sweden University. From the very beginning we tried hard to divide all work evenly. From collecting background information to the implementation we worked side by side and benefited from each other´s knowledge and skills when facing challenges. Two solutions to the problem were developed, one mainly using JAVA and one using CAA (C++ API). Both of us worked on these but since our programming knowledge in each language differed slightly, Sairam was more involved in the JAVA solution, while I focused on the CAA (C++ API) solution.

1.5

Report Introduction

This report is divided into 6 parts:

Chapter 1. A brief introduction regarding the problem specification. Chapter 2. Background knowledge, introduction of the product structure, system components, system architecture and development environment.

(14)

Chapter 3. Project specification and goal.

Chapter 4. Presentation of system design and methodology.

Chapter 5. Different proposals for the solution, the analysis and comparison regarding different solutions, implementation, obstacles and result.

Chapter 6. Conclusion and future work

1.6

About Scania

Scania is a major and leading automotive manufacturer for producing heavy vehicles. It manufactures heavy buses, trucks, and industrial and marine engines. It also offers transport solutions and long term commitment for customers.

Scania has over 100 years of history; today´s Scania has more than 1600 sales and service stations globally and the number is still growing. There were over 70,000 Vehicles produced in Scania in 2011. The major production units are in Sweden, the Netherlands, Brazil, France, Argentina and Poland.

In today´s Scania, modular systems provide a huge variety of specifications to meet varying needs for different customers. Customers can order a vehicle that is uniquely adapted for their needs. This also means there are no duplicated models of vehicles produced in Scania.

In order to be able to meet the diverse requirements of customers, modular approach with the support of reusable components is used to increase the efficiency of configuring different products.

Infomate is a global world-class IT provider for Scania, providing IT services supporting the business needs.

(15)

Chapter 2

Background

Information

The title of the thesis is ¨A Step Implementation For Product Structure Data Exchange¨. There are three key concepts: ¨Step¨, ¨Product Struc-ture¨and ¨Data Exchange¨, all of which will be explained for those without the relevant background information.

Firstly, we introduce ¨Step¨, which is an ISO standard introduced in section 2.4; secondly there is the ¨Product Structure¨, which is presented in section 2.1, and ¨Data Exchange¨, which is introduced in section 2.4 along with ¨Step¨.

This chapter is mainly about the introduction regarding the background knowledge, and is divided into five parts:

Section 2.1 Gives a brief introduction regarding the knowledge of ¨product structure¨.

Section 2.2 Introduces components in the existing system and the function-ality regarding each component.

Section 2.3 Gives a high level architecture of the system composed by com-ponents introduced in section 2.2 and the work flow of the existing sys-tem.

Section 2.4 Gives a introduction of ECCO which is a component applied in the existing system along with an ISO standard ¨Step¨.

Section 2.5 Introduction regarding the development environment.

(16)

2.1

Product Structure

2.1.1

Product structure concept

A product is formed by several different units. Within each unit there are various components that has to cope with one another. Each unit works with other units in order to maintain the functionality of the product. Product structure is a hierarchical decomposition of a product and separates units and describes the relationship between them and makes the configurations uniquely based on different requirements made by customers.

Below is a simple example to describe the product structure.

Figure 2.1: Example of product structure 1

Figure 2.1 shows part of the structure of a car, which consists of several sub components such as a body, interior and chassis. Windows and doors are parts of the body. Engine and breaking system are parts of the chassis. The engine is connected to the body with several components, so the engine is linked with the body by the concept of a relationship.

Figure 2.2: Example of product structure 2

All items such as engines, doors and windows are structured and the rela-tionship between them is formed in the product structure.

(17)

2.2. SYSTEM COMPONENTS

2.1.2

Breakdown

Product breakdown is complete or parts of structures in a product structure. That means that breakdown describes the structure of a product or part of this product and the component relationship in the structure.

For example, the engine of a car includes different parts which have different interfaces with other parts.

2.2

System Components

2.2.1

SPECTRA

SPECTRA is IBM mainframe, general product structure management sys-tem for product structure. It is a relational database which saves all product data in mainframe system and provides customers detailed data descrip-tions, including parts structures, rules, objects, properties and orders. It also exports the configured structures by formatting the file in XML. Scania uses AROS interface to enter the data to SPECTRA. The following picture shows the general view of AROS application.

(18)

2.2.2

CATIA

Before the introduction to CATIA, there is a short introduction regarding a company, Dassault Syst`emes.

Dassault Syst`emes: [1] is a world leading company in providing Prod-uct Lifecycle Management (PLM) solutions for industrial process. Dassault Syst`emes develops and manages PLM solutions and applications that sup-port business processes and provide 3D visualization of the entire lifecycle of products from conception, design, manufacture, maintenance to recy-cling.

Scania uses CAD(Computer Aided Design) to develop and design its own products. To find as much defective parts as possible, Scania simulates the product using 3D visual tools. It takes products (CATIA, ENOVIA) pro-vided by Dassault Syst`emes to design parts for vehicles before production and assembly begins.

CATIA: Computer Aided Three-dimensional Interactive Application, is a multi-platform CAD commercial software suite developed by Dassault Syst`eme. CATIA supports each stage of PLM, from conception to design, manufacture, and recycling. CATIA covers different kinds of engineering, including graphical design, shape design, mechanical engineering and equip-ment design. It is also used in various areas and industries, like automotive, construction and so on. CATIA provides ways to customize the application by using C++ programming language via CAA.(component Application Ar-chitecture, which will be introduced in section 2.5.1 on page 27.

(19)

2.2. SYSTEM COMPONENTS

2.2.3

ENOVIA

Before presenting ENOVIA, a concept should be explained: PDM.

PDM(Product data management): In product lifecycle management, there is a data management system that governs the data for the product, including the creation, management, and publication of the data. The func-tionality of PDM is close to a database system, it saves all the product data used in PLM. The data PDM keeps track of includes the specification of the product, different types of the materials, and specification for the development.

ENOVIA : Enovia Virtual Product Modeling products offers product data management for virtual models and is integrated with design, engineering and analysis solutions from Dassault Syst`emes, providing the collaborative platform for the company´s PLM solution.

ENOVIA provides vaulting, version and data management features to man-age parts created in a CAD-application. It uses graphical tools to edit the product structures and configurations. It is the database repository and data management system for CATIA.

(20)

The following graph describes the relation between CATIA, SPECTRA, and ENOVIA:

Figure 2.6: Architecture of CATIA, SPECTRA and ENOVIA When a CATIA user intends to order a breakdown in SPECTRA, the data would be generated from SPECTRA and transferred to ENOVIA in a spe-cific format which ENOVIA recognizes and then ENOVIA transfers the data back to CATIA.

2.2.4

SIAM IP MQ

SIAM IP: Scania integration platform, API provided by IBM. To be able to batch integration between SPECTRA and ENOVIA, two components of SIAM IP are involved, FTP-adapter and IBM MQ.

Figure 2.7: SIAM MQ structure

FTP-adapter: used to move files from SPECTRA to SIAM IP server and then place them on MQ queue.

MQ: Message Queue, it is used to provide message passing service and is a software tool used to queue messages(XML file) coming from the SIAM IP server, and communicates with the JAVA Migrator which takes the role as a batch job manager to communicate with ENOVIA.

(21)

2.2. SYSTEM COMPONENTS

2.2.5

JAVA Migrator

Java Migrator is a Scania developed batch job manager, and is written in the JAVA programming language. It is a key component which takes the responsibility for the integration and migration of data received from the upper layer components.

The functionalities can be summarized into three parts:

(1) Java Migrator communicates with MQ to be able to receive the incoming transactions (XML files) sent from SIAM IP;

(2) Transformation, which means the XML file format would be transformed into Enovia readable files (the component that takes this responsibility called ECCO, which is the key component in the project, it will be described later in the section 2.4);

(3) Interaction with Control-M (a job scheduler, which will be presented later in the section 2.2.7) to be able to synchronize with other batch activities and run the import jobs in Enovia server;

To keep the system running normally, The Java Migrator has to communi-cate with Control-M as soon as it gets a transaction. It supports parallel threads running in the system to improve the performance.

(22)

2.2.6

ECCO

ECCO is an EXPRESS-based toolkit developed by the german company PDTec [5], which is used to provide an environment for specification and manipulation of the mapping between different data models. The ECCO toolkit is the key component in the whole project. Section 2.4 will give a detailed introduction regarding to ECCO tookit and the related step stan-dard applied in ECCO.

2.2.7

Control-M

Control-M is an enterprise business integrated scheduling solution from the software company BMC Software.

The major functionality of Control-M is centralized control of the job schedul-ing. It is a job batch scheduler used to import the files or messages to ENOVIA server; it supports bat-scripts, VB-scripts, VB-Programs, Java-scripts, Java programs, shell-script. In this thesis project, Control-M is used to schedule jobs from ECCO to Enovia server.

(23)

2.3. SYSTEM ARCHITECTURE

2.3

System Architecture

Here is system high level architecture, including each component represented in the section 2.2 in this chapter.

(24)

Figure 2.9 gives a high level picture according to the system running cur-rently and shows the procedure of messages generated by SPECTRA, con-verted to Enov DataX which is the format accepted by ENOVIA, then it will be transferred to ENOVIA server.

The main transaction starts from SPECTRA when a user orders a new breakdown in SPECTRA. When the transaction is generated, the specified configuration of the product is generated. SPECTRA generates an XML file and the file will be transferred into the Scania integration platform SIAM IP, which puts the message into the MQ queue.

The JAVA Migrator checks the incoming new messages from the MQ queue continuously. As soon as a new message is available, the JAVA Migrator will download it into the ENOVIA server and by using the component ECCO, the original XML file will be converted into a Scania step file as an intermediate file and finally generates Enov DataX format, which Enovia accepts. The import job is put in queue in Control-M, waits for the Control-M to signal the import and then begins to run the import into ENOVIA. During the entire transaction from SPECTRA to Enovia, the information is represented on three files: an XML file, a Scania step file and an Enov Datax step file.

XML file: the XML generated from SPECTRA is a simple and readable file which represents the data structure of the product in XML format. The data includes all elements in the breakdown and the relationship between elements. The inherited relation covers the child and parent or grandparent or great grandparent. In each element, the object has attribute, type or ID. Each XML file includes a unique root object and the root object is the ancestor of all other objects. The object carries the unique transaction ID, which is important to identify for the following process.

Scania Step file: this is a step file which is the first step of the trans-formation, which means, this step file is an intermediate result; the data resource of this step file is the XML file described before. The Scania step file reconstructs the original XML file and defines the data in step file. The reason for the existence of this intermediate step file between SPEC-TRA and Enovia is twofold: one reason is that it is an independent file which means any change in XML file or Enov Datax file would not effect this file, another reason is that once data represented on the Scania Step schema, by means of EXPRESS-X in the second transformation step , it is easier to generate Enov Datax.

Enov Datax file: acceptable file by Enovia, a more complex format. The resource of the mapping is the scania step file, schema of the Scania step file, schema of the Enov Datax file and the mapping file represented in EXPRESS-C. Regarding schema, it is an abstract modeling data file de-fined by using EXPRESS language, which was introduced earlier.

(25)

2.4. STEP STANDARD AND ECCO

By importing the Scania Step file as a data source and schema as a data structure and definition, the target file Enov Datax step file is translated.

2.4

STEP standard and ECCO

Before the introduction of the development environment, there is an impor-tant concept called ¨STEP¨ which is described in this section. STEP is the key standard used in the project and it is used in the ECCO component in the existing system.

ECCO is used in the current system and is to be replaced with a new module.

2.4.1

STEP standard

STEP [6], stands for Standard for the Exchange of Product Model Data, and is a set of ISO standards (ISO 10303), which describes the representa-tion and exchange of digital product manufacturing data.This ISO standard is officially called ¨Automation systems and integration - product data rep-resentation and exchange¨ ISO 10303 can represent 3D objects.

STEP is used in a lot of different industrial areas; it has been used in me-chanical, construction, electricity & electronics, automobile, architecture, etc. It has also been applied in fields including design, maintenance, manu-facturing, production, data reusability and so on. It is designed and applied in the entire period of product design, implementation, simulation, in other words, the whole lifecycle.

2.4.2

STEP file

STEP File [7] is the most widely applied data exchange file of STEP. The format of a STEP-File is defined in ISO 10303-21 Clear Text Encoding of the Exchange Structure.

STEP is divided into different parts, each part represents different function-alities according to the data exchange.

2.4.2.1 EXPRESS

International Standard ISO 10303-11:1994, specification of description meth-ods, the EXPRESS data modeling language is used to give a general

(26)

descrip-tion of data models. Functionalities:

EXPRESS is a data specification language, based on the entity relation-ship model of data, and also includes constraint specifications. It is widely used in many different areas of business, industry, research and academics. Modules described by the EXPRESS language can be performed by using different applications. It can be read or edited very easily and it is designed for abstract product data modeling. It can also be used in mapping lan-guage (EXPRESS-X which will be represented later in the section 2.4.2.4) in multiple implementation forms.

The basic fundamentals includes Schema, Entity, Attributes, Type and Rule.

Schema defines a general structure of the product data specification. Data types include string, integer, real, binary, logical, Boolean as well as in all other programming languages.

Entity refers to a whole collection of information which represents concep-tual or real objects in the world. Entity describes the value, relationship, structures, etc.

Attributes refer to the property of the entity or objects.

Here is a simple example to represents the general information of a employee in a company. Example(2.1): ENTITY employee; name: STRING; ID: INTEGER; Age: INTEGER;

Company Name: company; END ENTITY;

In the example, the attribute called Company Name will be represented by other classes in the model. The ¨name¨ in the model is represented by a string(character), which is an atomic type in EXPRESS. The ¨ID¨ in the model is described by an integer, and the ¨Age¨ is defined by an integer in the example.

So similarly, here we could model a Company Name class to gather some information about the company.

(27)

2.4. STEP STANDARD AND ECCO

name: STRING; END ENTITY; 2.4.2.2 Step file

Specification of implementation methods, an EXPRESS-driven data ex-change file specification to save data model into files. The format of the file would be : xxx.p21.

Example(2.2):

#1= employee (’Eric’,’1234’, ’39’, ’Scania’) ;

#2= employee (’Lena’,’1235’, ’56’, ’Scania Informat’) ; #3= employee (’Linda’,’12346’, ’45’, ’Scania CV’) ; #4= employee (’John’,’12347’, ’32’, ’Scania’) ;

2.4.2.3 SDAI

ISO 10303-22:1998, SDAI, which stands for Standard Data Access Interface, is an EXPRESS-driven application programming interface to create, delete, retrieve, set EXPRESS defined data. It provides a binding with C, C++, JAVA programming languages. A more detailed description will be found in later section 2.5.2 on page 29.

2.4.2.4 EXPRESS-X

Part of ISO 10303, EXPRESS-X specifies a mapping language for a relation-ship description between different data formats in EXPRESS schema. This means that EXPRESS-X is an evolving language describing the mappings betweendifferent entities, from one EXPRESS schema to another EXPRESS schema that describes the view of the first schema.

(28)

Figure 2.10: Overview of EXPRESS-X: [8]

Figure 2.10 gives a brief view of the relations between the different models. The ¨view model¨ refers to the view of the original information model. When we are using the EXPRESS-X to map different schemas, we use a EXPRESS-X schema called mapping schema to perform the real mapping between schemas.

The following figure 2.11 shows the schema mappings in an EXPRESS-X specification.

(29)

2.4. STEP STANDARD AND ECCO

In figure 2.11, the mapping schema, which is represented as orange frames defines the relationship between Base model and View model. In each model, EXPRESS is used to define the schema while the mapping schema is defined in EXPRESS-X mapping language.

From figure 2.11, we could clearly see that the mapping schema takes the role as a middleware component which connects two different schemas. When we are trying to map schemas, the most important job that EXPRESS-X should do is to make the whole mapping happen and run in a smooth way. EXPRESS-X compiler takes the role. EXPRESS- X compiler would convert the information from one schema to another schema.

Here is a a simple example to make the concept more clear and easy to understand.

Example(2.3) Base Schema:

SCHEMA Base schema; ENTITY person; name: STRING; ID: INTEGER; Age: INTEGER; END ENTITY; ENTITY family;

Number of people: INTEGER; member: person;

END ENTITY; END SCHEMA; View Schema:

SCHEMA View schema; ENTITY company; name: STRING;

employee name: STRING; employee age: INTEGER; END ENTITY;

(30)

END SCHEMA; Mapping Schema:

SCHEMA MAP Mapping Schema; GLOBAL

DECLARE base INSTANCE OF Base schema; DECLARE view INSTANCE OF View schema; END GLOBAL;

VIEW company ; FROM (person, family )

WHEN ((person. name = family. Member. name) And (Not (family. Num-ber of people < 5))

BEGIN VIEW

Company. Name : = ´SCANIA´;

Company. employee name : = person. Name; Company. employee age : = person.age; END VIEW;

END SCHEMA MAP

In the example, Base Schema describes the source schema which defines two entities, ¨person¨ and ¨family¨. ¨person¨ describes the basic informa-tion of the person, including name, ID, Age and the data types of each attribute. The entity ¨Family¨ defines the attributes of the family includ-ing ¨Number of people¨ and ¨member¨, as well as the data type of each attribute.

View Schema describes the target schema which defines the entity ¨company ¨. The attributes ¨name ¨, ¨employee name ¨, ¨employee age ¨ of the entity are defined. Both base schema and view schema are defined in express language.

The mapping schema in the example is the key schema which performs the mapping between the base schema and view schema. The mapping schema first sets a condition by using ¨WHEN ((person. name = family. Member.

(31)

2.4. STEP STANDARD AND ECCO

name) And (Not (family. Number of people < 5))¨ which means before the mapping happens, the ¨name¨ of ¨person¨ in base schema has to equal to ¨name¨ of ¨member¨. In this case member refers to entity ¨person¨ in the same base schema. Also, the ¨Number of people¨ in the entity family has to be larger or equal to 5.

After setting up the conditions, the following mapping performs the real mapping. It takes the ¨name¨ of entity ¨company¨ in view schema map to the name ¨SCANIA¨, the ¨employee name¨ of ¨Company¨ is mapped to the ¨name¨ of ¨person¨, and the ¨employee age¨ of ¨Company¨ is mapped to the ¨age¨ of ¨person¨.

From the example we could easily understand that the relationship between the person, family and the company. In the example, a global declaration defines the name of the base schema and the name of the view schema for the mapping, which is uniquely defined.

But since the Express and Express-X are just abstract modeling languages to describe the data type and mapping schema, we need source data defined in the step file (xxx.p21 file) based on base schema to perform the real mapping and get the target step file.

The following step file(xxx.p21) gives the source data based on the base schema and target step file(xxx.p21 file) after the mapping.

Source step file:

#1= person (´Jen´,´12345´,´26´) ; #2= person (´Tove´,´12353´,´37´) ; #3= person (´Erik´,´34345´,´42´) ; #4= person (´Linda´,´90545´,´53´) ; #5= family (6, ´Jen´) ; #6= family (4,´Linda´) ; #7= family (7,´Erik´ ) ; #8= family (5,´Julia´) ; Target step file after mapping:

#1= company (´SCANIA´,´Jen´,´26´) ; #2= company (´SCANIA´,´Erik´,´42´) ; 2.4.2.5 EXPRESS-G

EXPRESS-G is a graphical form for the product data modeling language; it represents the data by using graphs or charts. It is a easy way to understand the data structure and the relationships between data. It assists the devel-opment of the product data description and mapping of the schemas.

(32)

Here is a simple figure 2.12 describing the relations in Example 2.1.

Figure 2.12: EXPRESS G example

2.4.2.6 EXPRESS-C

EXPRESS-C is an extension of EXPRESS, which has the upward compati-bility with EXPRESS.

It adds new attributes and new methods to EXPRESS, which means it adds more semantics to the definition of an entity and it also adds preconditions and postconditions as well as operations. At the same time, EXPRESS-C includes an execution model as well as the construct to process persistent data.

The most important and useful functionalities added in EXPRESS-C is C++ code embedding functionality, which means EXPRESS-C is compiled to C++ and native C++ code can be embedded into EXPRESS. So these functionalities makes it easier to specify the mapping algorithm. In another word, EXPRESS-C narrows the gap between the lower level data manipu-lation language C or C++ in combination with SDAI which provides the interface with the lower level language and abstract data modeling language EXPRESS.

By specifying the mark of adding C++ code, the code in EXPRESS is compiled and run as a normal C++ programming code.

(33)

2.4. STEP STANDARD AND ECCO SCHEMA person ... BEGIN C++ #inlcude < stdlib.h > int main() { ... Class ABC ... } ... END C++;

Procedure start(type : INTEGER) BEGIN C++

long start type = @type@.get long(); start(int(start type));

END C++; END procedure ; END SCHEMA ;

By using EXPRESS-C, EXPRESS is closer to C++ programming language, and has wider interface with other programming languages.

The following figure shows a brief comparison of the EXPRESS-C /X ap-proach with the traditional apap-proach.

(34)

In the traditional approach, the semantic gap between EXPRESS and C/C++ SDAI is huge since EXPRESS is an abstract modeling language and C or C++. SDAI are more low level programming languages. But C/C++ SDAI was the only interface to support the processor and implementation. But in the EXPRESS-C/X approach, it supports both EXPRESS, C++ and SDAI, so it can be implemented and recognized by the processor. So the usage of EXPRESS-C as a data manipulation language minimizes the workload for the development of STEP implementation.

By the use of the EXPRESS-C/X approach, a reduction of up to 85% in mapping specification code length and up to 70% in development time can be reduced.

2.4.2.7 Relationship between different parts in STEP Figure 2.14 below describes the relations and different parts of STEP.

(35)

2.4. STEP STANDARD AND ECCO

2.4.3

ECCO Toolkit

ECCO is an EXPRESS-based toolkit developed by the German company PDTec, which is used to provide an environment for specification and manip-ulation of the mapping between different data models. The transformation between various data models are very different from each other, so ECCO supports heterogeneous programming languages and development platforms, including C, C++, JAVA, C#, Perl, TCL and Visual Basic.

ECCO toolkit is available for different operative system platforms and com-pilers. These platforms include AIX, HP-UX, IRIX, Sun Solaris, Win32 and the GNU compiler. ECCO supports the data modeling and definition language EXPRESS as well as the data manipulation language EXPRESS-C.

The descriptions of EXPRESS and EXPRESS-C are covered in more detail in the previous sections. ECCO toolkit is a good application for EXPRESS-C, since it can process large amounts of data and minimize the coding work-load. ECCO toolkit is a powerful transformation tool for the mapping be-tween different data models. In the ECCO toolkit, both EXPRESS-X and EXPRESS-C can be used in combination or interchangeably.

2.4.3.1 ECCO functionality

The major functionality of ECCO is for building EXPRESS-based integra-tion and transformaintegra-tion based on different data models.

To be able to satisfy different requirements from different customers in various research fields or industrial areas, and also to be able to manage EXPRESS-based solutions and applications, ECCO is designed to be a mod-ular system, which means that the ECCO toolkit is divided into several components according to different functionalities.

(36)

Figure 2.15: overview of components of ECCO toolkit [5]

2.4.3.2 ECCO compiler

A powerful compiler which can handle several different specification lan-guages, including EXPRESS, EXPRESS-C, EXPRESS-X. Users can get the specified target objects by choosing from different options. Like other com-pilers, the basic functionality of the ECCO compiler is to check the correct-ness for semantics of the imported schema and generate correct applications. Also, when EXPRESS or EXRESS-X and EXPRESS-C has any version up-dates or changes, the ECCO compiler follows the latest change to update its own functionalities.

(37)

2.4. STEP STANDARD AND ECCO

2.4.3.3 ECCO API

Figure 2.15 shows the major structure of the ECCO toolkit and it´s easy to grasp it from the figure. One of the most important features of ECCO is the communication functionality between ECCO and external applications. ECCO API is applied to communicate with JAVA Migrator to perform the integration and migration of data.

ECCO API is not only used to invoke EXPRESS and EXPRESS-C, but can also haccess individual instance. ECCO API also provides semantic interfaces to lower-level programming C, C++, JAVA.

2.4.3.4 ECCO data adapter

Is used to read or write databases directly from EXPRESS-X applications and provides the mapping between different databases. It also allows the ac-cess to the STEP files(EXPRESS-based). It is an interface between external data sources and applications.

(38)

In the figure 2.16, schemagen refers to the tool to generate schema and the data access library makes it possible to enable the EXPRESS-based database access.

In the current Scania system, the major task for transformation from one data model to another is done by ECCO. It is a third party application and it needs to be maintained, The frequency of the mapping activity between different schemas are not as common as usual, It is also difficult to maintain the EXPRESS-C knowledge; ECCO currently not support on upper AIX 4.3.3. so the major task for this thesis is to make a new module to replace ECCO, detailed in project description in chapter 3. .

The relationship between ECCO and Java Migrator is closely correlated. Java Migrator has several interfaces with ECCO, since JAVA Migrator is written in JAVA, so there are several objects in JAVA Migrator that are used to communicate with ECCO including the message parser, objects creation, work dictionary setup, etc. All modules that communicate with ECCO in JAVA Migrator has to be updated after the replaced module takes the role of ECCO.

2.5

Development Environment

Software components used in this project, including CAA module and Java module.

2.5.1

CAA/C++

This section will give an introduction of the CAA module and SDAI used in the module, and includes the general background knowledge and function-alities which used in the development.

CAA V5 stands for Component Application Architecture Version 5, devel-oped by Dassault Syst`emes, and is a development platform which built upon C++ features supporting the development of products in a great range of en-gineering, industrial, academic domain integrated with Dassault Syst`emes’ products CATIA, ENOVIA, DELMIA. To be able to offer customers an en-vironment for developing their specific requirements, CAA provides a mod-ularization programming of the system. The customized solution is based on the different customers´ different requirements so it is flexible and con-venient for different customers to develop their own products.

CAA V5 tools are set up and migrates with Microsoft Visual Studio 2005 environment. Features are similar but some conceptions are different in detailed.

(39)

2.5. DEVELOPMENT ENVIRONMENT

Workspace:

In CAA, the workspace takes the responsibility of organizing and storing de-velopment projects. Workspace has its own name defined by the developer. Workspace could include more than one framework.

The framework in CAA is a mapping to projects. A project is defined as a set of files that produces a program/library or a final binary file. i.e. the framework can also be viewed as a collection of a set of modules work in cooperation. It has the same level in the architecture as project.

The structure can be represented as the following figure 2.17:

Figure 2.17: CAA architecture Module:

As described previously, modules are represented as independent and reusable units in CAA V5. Based on the functionality requirements, it is allowed to add multiple modules in the framework. They can be related or each of them can be independent.

In each module, there is an entity called interface. The component can be accessed by the interface. Header files should be included in interface. The concept of interface is actually represented in two ways, one is in the startup project module, one is in the subnet modules.

In the startup project, the interface has three different categories.

PublicInterfaces: the interfaces included can be accessed by the frame-works outside of its own; the feature is similar to the public class in C++. ProtectedInterfaces: contains the interfaces that are available for the frameworks of the modeler to which this framework belongs. Header files in ProtectedInterfaces cannot include header files located in a folder with a lower level of visibility like PrivateInterfaces.

PrivateInterfaces: contains interfaces that the framework wants to pro-vide but for its own needs. These interfaces are not visible outside the framework scope.

(40)

access scope. Customers can use different interfaces depending on different needs.

In the source file folder included in the module, the major program (usually .cpp file ) can be added and run as an executable file. Also, make files suffix ¨mk¨ is placed in the form of ¨Imakefile.mk¨ in each module. The functionality of makefile is as same as the regular makefile, which links to the specific components, systems, or some specific requirements required in the project.

Also, in startup project, there is an entity called ¨IdentityCard¨ which is designed as an interface to the framework.

2.5.2

SDAI

In previous sections, the SDAI has been introduced briefly. In this section, the SDAI will be described in a more detailed way.

SDAI stands for Standard Data Access Interface. It is an EXPRESS-driven application programming interface used to create, delete, retrieve, set EX-PRESS defined data, such as STEP API. It provides a binding with spe-cific programming languages such as C, C++ and JAVA programming lan-guages.

SDAI uses EXPRESS compiler to generate code for EXPRESS schema. In CAA, SDAI is a binding component used to provide an interface with the programming language, which means that when a step file needs to be con-verted into another format by using EXPRESS schema, CAA would pro-vide SDAI environment to support the compiling and running of the whole EXPRESS-Based schemas and step files. In current supportable CAA mod-ules, there are some important SDAI components used in the project. The creation of SDAI module:

The most basic functionality provided by a specific module is to create and delete the SDAI modules. To be able to convert the source file to the target file, there is a specific location to store the SDAI module to be able to communicate with CAA.

The compiling from EXPRESS model to C++ module in CAA: There is a framework named SDMRuntime, which takes the responsibility of compiling from EXPRESS model to C++ module in CAA.

By using specific CAA components defined in the CAA environment, the makefile in the module performs this functionality. This module is the key component in SDAI, since this is the key interface integrated with program-ming features.

(41)

2.5. DEVELOPMENT ENVIRONMENT

The feature of compiling from EXPRESS-X to C++ module is a key feature of the development of EXPRESS-X based schema converting.

Similar to the compiling from EXPRESS to C++ module, the CAA com-piler takes the role of compiling from EXPRESS-X to C++ by using some specific modules in CAA. Also, the Imakfile.mk will include all the modules related.

One of the deficiencies of the application to convert EXPRESS-X schema and EXPRESS schema in CAA module is the limitation service and functionality from Dassault Syst`emes. In order to be able to convert from a step file (It is called Scania newStep file in the project ) to the format of another step file (target step file, it is called ENOV Datax in this project), we are suppose to get four different files, which are: the source file (Scania newStep file) , the EXPRESS Schema which describes the Scania newStep file, the EXPRESS-X mapping file (which is used to map between different schemas), and the EXPRESS schema which describes the target step file ENOV Datax file.

The relationship between the different step files and schemas can be repre-sented in the following figure 2.18:

Figure 2.18: SDAI source and target files

When we are trying to map between different schemas, we first need to use interface in the CAA module to create SDAI module, then the SDAI module would run with the source step file and the result of compilation of EXPRESS and EXPRESS-X schemas.

(42)

But in the current Dassault Syst`emes CAA module, there is no functionality to create a SDAI module to fully support the reading and writing of the source step file Scania Step File. The target step file ENOV Datax file could not be gotten directly by using the current solution provided by Dassault Syst`emes.

2.5.3

JAVA/JSDAI

2.5.3.1 JAVA

JAVA is an object oriented programming language, generally and widely used. Java applications are organized mainly in classes, which takes the advantage of making the programming module as little implementation de-pendent as possible.

JAVA is used as a programming language developing the major module in the project. Java has similar features with EXPRESS-C mapping language, so it is easy to organize and structure the whole software development in Java. Especially when using EXPRESS-C to fetch specific entities in a defined class, Java needs only to refer to the attribute of the entity and get all the information needed. Mapping is usually represented as a format of some equation, not in an algorithm way, but in an object oriented way. Java classes can also support good conception of modularization in EXPRESS-based data mapping languages.

2.5.3.2 JSDAI

SDAI has been presented in the previous sections, JSDAI is similar to SDAI but in Java way. JSDAI is a Java-based API for EXPRESS-based data models. Since EXPRESS is widely used in a lot of areas, more and more requirements from customers are proposed and more programming platforms needs to be supported.

Besides the features similar to SDAI, JSDAI also added several new features and properties.

(1)JSDAI supports the execution of functions, expressions in EXPRESS schemas;

(2)JSDAI supports different APIs in parallel. The APIs include the binding of Java classes and interfaces for the attributes of elements. Each EXPRESS element can be accessed by Java classes; the mapping between source schema and target schema to be able to get the target data model. It also supports the SDAI dictionary.

(43)

2.5. DEVELOPMENT ENVIRONMENT

The Express compiler in JSDAI compiles the EXPRESS schema to be able to run for JSDAI runtime.

The working process of the compiler takes a few steps and can be represented as the following figure 2.19:

Figure 2.19: JSDAI EXPRESS Compiler [10] Supported platforms:

JSDAI supports applications run only on Java platforms, including Java Runtime Environment 1.4, Java 3D for JSDAI 3D viewer. Old JSDAI is supported for including Java Runtime Environment 1.2 and 1.3.

JSDAI Runtime Platform:

JSDAI runtime is an API to manipulate, running on product data. To be able to make EXPRESS schema run it is used combined with the JSDAI EXPRESS compiler which was introduced in the previous section. JSDAI runtime platform supports the SDAI dictionary and session schema. Related to the project, JSDAI is mainly used for compiling, generating and manipulating the EXPRESS and EXPRESS-X based schema to make them run on the Java platform. Several components are included and combined in JSDAI runtime platform to make the system work well.

(44)

Chapter 3

Project Specification and

Goal

3.1

Project Specification

In the existing system, ECCO takes the responsibility for the transformation between different data models. It transforms the XML file to an intermediate file called ¨scania step file¨ and finalizes the transformation by producing a final format which the ENOVIA server can accept, the ¨Enov DataX file¨. However, ECCO is aimed to be replaced by a new module.

Here is a list if two major necessarily reasons to replace the ECCO compo-nent.

(1.) In today´s Scania, ECCO no longer supports the version of AIX in use on the development and production servers. This causes a high risk and a major obstacle when the mapping has to be rebuilt.

(2.) ECCO is developed by the German company PDTech [5], i.e. it is a third party component. It requires highly specialized knowledge such as data modeling language, data specification language and the standard data access interface between the abstract language and lower level language. It is difficult to keep the specialized knowledge in the development team. The major task in the project is to develop an in-house CAA module or a standard component to show whether or not it is feasible to replace ECCO.

(45)

3.2. PROJECT GOAL

Figure 3.1: Project Specification

3.2

Project Goal

This project is mainly about a transformation between different data mod-els.

Figure 3.2 specifies the source file and target file, the figure separates the whole task into two parts.

(46)

Figure 3.2: Source file and target files specification

In the first step, the source file refers to the XML file and the Scania schema. XML is explained in section 2.3. Scania schema is an express file which describes the attributes of entities in the XML file and the child-parent relationships between different entities in the XML file. Basically, it is a structure specification for the XML file. The XML file should be loaded into the designed module, run together with Scania schema, generating the intermediate file, called the Scania step file.

After the intermediate file is generated, it would be loaded into the second module. In the second module, the source files are the Enovia schema, Scania schema, the mapping file and the Scania step file. Enovia schema is an express file which represents the complicated relationships between each element in the target Enov DataX file. The Scania schema is the same schema used in the first module, the mapping file is an EXPRESS-X file which maps the Scania schema to Enovia schema file. By using this module, the Scania step file is loaded as a source file and the mapping file takes the transformation from Scania schema to Enovia schema and the target file Enov DataX file is generated.

The intermediate file is required, since the file is independent of changes in both SPECTRA and ENOVIA. Furthermore, it is more flexible and less com-plex to maintain than direct mapping from SPECTRA to ENOVIA. The new module is expected to be developed by using CAA or other stan-dard modules. Here is the file architecture between source file and target

(47)

3.2. PROJECT GOAL

file.

(48)

Chapter 4

Module design and

methodology

This chapter is focused on the design flow and methodology used in each design step.

4.1

Design flow, methodology

Figure 4.1 shows the design flow from system level to lower level. The design of the solution in this project mainly follows the design flow and methodology as shown below.

The design flow is divided into two levels: system level and lower level. The system level is a popular research area that makes the system run in a more well-designed way. The goal is to optimize the system run using a more efficient method.

The lower level design is actually a coding design phase in the whole design flow. It takes the integration of software and hardware, clarifies simulation between the software and hardware, code development, code generation, etc. Finally it makes a prototype to try to run the system.

System level:

The design flow starts from the informal specification constrains, which gives a very general and informal instructions regarding to the project.

Modeling followed by informal specification refers to the generation of for-mal specification of the functionalities in the model. The model could be decided to be used based on different modeling concepts. Model in this stage can refer to, for example, the C model, UML model, etc. Regarding

(49)

4.1. DESIGN FLOW, METHODOLOGY

Figure 4.1: System Design Flow [11]

the project, the model is designed in CAA model and Java model in different proposals.

(50)

In the system model step, the first task is to decide on the architecture. The selection of the system architecture is one of the most important design tasks. The high level architecture regarding to the figure 2.9 is mainly done by Scania itself. But since the task is to replace one of the models in the architecture, the new component has to be integrated with the other components in the system.

The model architecture had several proposals. The analysis of all proposals will be discussed in the later chapter 5. In order to be able to make an ap-propriate decision regarding the solution, the estimation is done in different ways. In each solution the advantages, disadvantages and limitations are considered.

In figure 4.1 there is a loop covering the architecture selection, estimation, mapping and scheduling work in an iteration way until an appropriate so-lution is selected and decided. If there is anything in the stage that needs to be adjusted, it is proposed. During the whole period of architecture se-lection and estimation, mapping, time consuming and cost limitations are always considered and satisfied.

Scania currently has its own high level architecture but the optimization work never stops. New technology, methodology, software as well as hard-ware platforms are proposed daily in order to improve the product quality and higher the working efficiency.

Lower level:

In this level, the execution on a programmable processor, data flow, soft-ware model, API are all decided, as well as the hardsoft-ware platform. The hardware and software in this implementation phase have to be developed in a coordinated way. Relating to this project, we don´t have any special requirements for the hardware; a normal computer or laptop satisfies all the basic requirement. Regarding the software side, software development language such as Java, C++, EXPRESS, EXPRESS-X, and CAA API used has been described in chapter 2 .

Software generation in the figure is divided into different stages:

(1) Encoding implementation language, like Java, C++, EXPRESS, EXPRESS-X.

(2) Compiling of the code by using different software components.

(3) Code adapting to the existing operation system and environment. The data consistency should be considered and fulfilled.

(4) Testing and debugging of the new code.

Finally, after the implementation successes, a prototype is generated and this prototype should match the project goal.

During the period of testing, if there is any situation unsatisfied the project goal, the solution would be estimated again and the work will be started again from the architecture selection in system level design.

(51)

Chapter 5

Implementation

By following the methodology and design flow introduced in chapter 4, the system model is decided by processing architecture selection, mapping, scheduling, estimation stages on the system level. On the lower level, test-ing results decide if the proposed solution is accepted as a prototype or not. Also, the solution is proposed and implemented based on practicality and limitations of the system. Advantages and disadvantages of the model are also analyzed.

This chapter gives an exhaustive introduction for three different proposed solutions and implementations, obstacles and limitations.

To be able to satisfy the goal of the project, the whole solution is divided into two parts as introduced in chapter 3. The first part is designed to convert from the XML file to intermediate file, the Scania step file. The second part aims to convert from the intermediate file into the target file, the Enov DataX step file.

5.1

Proposed Solution 1 and implementation

5.1.1

Proposed solution 1: CAA + CAA

As described in the project specification in section 3.1, the intention of the project is to develop an in-house CAA module or another standard module to replace ECCO. CAA(C++ API) is highly preferred since it is widely used in Scania.

CAA is developed by Dassault Syst`emes and user manual and documenta-tions are provided by them. After we investigated and explored the docu-ments, the following solution was proposed.

(52)

Figure 5.1: Proposed Solution1

Regarding the figure 5.1, the whole solution is divided into two parts, each part is developed in the CAA module. The first CAA module takes the XML file and Scania Schema as input and gets the Scania step file as an intermediate file, the second CAA module takes the Scania step file as input. By compiling the mapping file, the target Enov DataX file is generated as a result. After the file is generated, it would be delivered into Control-M and imported into the Enovia server, as discussed in chapter 2, section 2.3.

Based on the investigation and the documentation provided by Dassault Syst`emes, the proposed solution is possibly executable, but during the im-plementation, there are some limitations and obstacles in CAA functionali-ties that became a barrier to progress the solution.

5.1.2

Implementation

In the first CAA module, the XML file is taken as the data source, with the help of CAA module, XML is supposed to be converted into a step format file. XML handles complex relationship between different objects. The following figure 5.2 represents the objects relationship in the XML file as an example.

(53)

5.1. PROPOSED SOLUTION 1 AND IMPLEMENTATION

5.1.2.1 HASHTABLE functionality obstacle in CAA

In the figure 5.2, there is an object names ¨object1¨, it has a child names ¨object1.1¨, then ¨object 1.1¨ has two children ¨object 1.1.1¨ and ¨object 1.1.2¨, each of them has children, ¨object 1.1.1¨ has ¨object 1.1.1.1¨ and ¨object 1.1.1.2¨, ¨object 1.1.2¨ has children ¨object 1.1.2.1¨ and ¨object 1.1.2.2¨.

This is a simple example to help understanding of the relationships between different objects in XML file. To be able to pass the XML as resource to the CAA module and convert to the Scania step file, XML parser functionality is needed to be able to recognize different hierarchy relationships between different objects. For example, ¨object 1.1.2.1¨ is the grandchild of ¨ob-ject 1.1¨, so in the CAA module, this relationship should be represented in this way: ¨object1.1.2.1¨ is on the second layer under ¨object 1.1¨, as ¨object 1.1.2¨ is on the first layer under ¨object 1.1¨. To be able to find the correct relationships for correct objects, HASHTABLE functionality is necessary:

index = f (key, arrayLength)

The HASHTABLE function calculates an index within the array from the data key, arrayLength is the size of the array. By using HASHTABLE, the index value would be found by Key, so that the hierarchy relationships between different entities would be found. But in the current CAA module, the HASHTABLE functionality is not supported.

5.1.2.2 Source file importing obstacle in CAA

In the second module, the intermediate file Scania step file is taken as the source file. To be able to be converted to the target file by using the mapping module, it needs to be recognized by the CAA SDAI model and data needs to be loaded into CAA. But currently CAA doesn´t support the import of the step file. Also it doesn´t support the customized functionality to support the step file import. This means, there is no source file that could be loaded into the module and it is impossible to get the target file. 5.1.2.3 Mapping language obstacle in CAA

Before starting the introduction regarding the third obstacle in the imple-mentation, there is a concept that needs to be described: provision docu-mentation.

In Scania, a specific document called provision document is suppose to be generated along with the target file to meet the system requirement. The

(54)

provision document includes some user information along with parts infor-mation in the breakdown.

In the ECCO component, this functionality is taken by using EXPRESS-C mapping language. It is a powerful mapping language because it could process C language when the user has put some specific mark in the map-ping language. But the CAA compiler could not process the EXPRESS-C language, it just recognizes EXPRESS-X language in a specific format. It became a big obstacle to compile the complex mapping between the Scania schema and the Enovia schema in the second CAA module.

Implementation of solution 1:

Figure 5.3: Implementation for proposed solution1

As was observed from the first solution, a new solution is necessarily pro-posed. The new development environment should have similar functionali-ties with SDAI and CAA. JAVA was selected.

JAVA could be used as development platform in conjunction with JSDAI. JSDAI is an open source API from LKSoft [12] which has the similar func-tionality with SDAI, it could process the EXPRESS data models and inter-act with JAVA. Also it could be finely integrated with JAVA Migrator in the system architecture.

5.2

Proposed Solution 2 and implementation

The new solution takes the responsibility of solving obstacles and limitations in proposed solution 1 to get the target file.

5.2.1

Proposed solution 2: JAVA + CAA

The solution is designed in two modules, the first part is developed in JAVA, and converts the XML file to a new Scania step file, which is different from the old Scania step file described in section5.1.

(55)

5.2. PROPOSED SOLUTION 2 AND IMPLEMENTATION

The second part is developed in CAA module, the reason for taking CAA module is because some necessary EXPRESS-X mapping functionalities are limited in JAVA and JSDAI, JAVA and JSDAI don´t support some mapping functionalities which CAA supports. Based on the documentation Dassault Syst`emes provided, it is possible to convert the new Scania step file into Enov DataX file which could be imported into ENOVIA server.

Figure 5.4: Proposed Solution2

5.2.1.1 JAVA module

5.2.1.1.1 Java programming language The Scania schema here is the old Scania schema but represented in JAVA classes. The reason for doing this is to avoid using JSDAI to recognize the old Scania schema defined in the EXPRESS format.

In the first solution, the HASHTABLE functionality is required so that different entities in the XML file could be recognized and organized, but CAA couldn´t fulfill it. JAVA supports the HASHTABLE functionality and makes the hierarchy relationships between different entities in XML file to be recognized. So the XML file is the data source, while the Scania schema here is similar to a filter and structure to get the entities in XML file and structure them in a hierarchy way.

(56)

5.2.1.1.2 New Scania schema In the first solution in section 5.1.2.3 we introduced the mapping language obstacle in CAA. In the second module of the first solution, the mapping between Scania schema and Enovia schema is complicated, EXPRESS-C language is used in the existing ECCO compo-nent to map the complex relationships. The following figure represents the complicated relationships in the old mapping module.

Figure 5.6: Complicated mapping relationships from the Scania Schema to the Enovia Schema

In figure 5.6, the left side represents the generic relationships between the objects in the Scania schema, while the right side represents the 119 entities in Enovia schema and the relationship between entities. The relationships between the left side and the right side became very complicated. It can only be handled by EXPRESS-C rather than other data modeling languages.

(57)

5.2. PROPOSED SOLUTION 2 AND IMPLEMENTATION

It is the reason why ECCO takes EXPRESS-C to perform the mapping. But in CAA, EXPRESS-X doesn´t have strong functionality to handle the complicated mapping functionality.

Figure 5.7 could help to understand the complicated mapping relation-ship.

Figure 5.7: Simplified view of mapping relationship

The complicated mapping relationship could be viewed in two parts, the first part handles the complicated features in the mapping. The implemen-tation of this part is very close to C implemenimplemen-tation. It helps to handle the complicated mapping features but not using the mapping language. The second part is the real mapping from the base schema to the target schema. EXPRESS-X is used in here.

To be able to make the second mapping module as simple as possible, The second solution separated the complicated mapping module into two parts, the first part in figure 5.7 is used in the first JAVA module, the second part (pure mapping) part is used in the CAA module.

The new Scania schema is created to handle the first part functionalities and is written in JAVA language. When express compiler is compiling the new Scania schema, it generates the JAVA libraries for the schema and the libraries are accessed in the JSDAI environment, then the data source in figure 5.5 will be read. Finally the new Scania step file is generated. The format of the new Scania step file is very similar to the target file but lack the mapping feature which is why it is left to the second CAA module.

At the same time, provision document which is described in section 5.1.2.3 is generated in JSDAI environment. The function of provision document generation is included in the new Scania schema.

JAVA module which handles the most complicated parts in the task, is developed and implemented successfully, the output file is a new Scania

References

Related documents

At the time of writing and during the time of the interviews the acquisition process between the Swedish Binar and French Mercura is best corresponding to step nine, implementing

In 3 dimensions we then find the beautiful feature that every non-coherent state will violate some pentagram inequality [4]—in complete analogy with the fact that every entangled

– A method for carving files out of raw data using a distinct header (start of file marker) and a maximum (file) size. This approach works because many file formats (e.g. JPEG,

The pointers to these pages are stored as record numbers, that is, the page offset is calculated by multiplying the record number by the record length of 512 bytes.. (In clipper

If the organization finds itself being on the first level of Håkansson’s (1991) model with little or no need to develop any further but still has to go through a

Hypothesis I: A firm which undergoes a listing change from Nasdaq First North to the Swedish main market Stockholm stock exchange is expected to experience an increase in the number

data_type1 int Data types DATATYP (int, float, char, etc) listed in DB. data11 DATATYP1 Here starts data1

Charges (APCs) for authors from affiliated institutions who wish to publish in the Press’s hybrid and fully Open Access journals, depending on the agreement. For a list