CAA Product Structure

Institutionen fr 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

Linkpings universitet
SE-581 83 Linkping, Sweden
581 83 Linkping
Institutionen fr datavetenskap
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, Linkping University
Examiner: Arne Jnsson, Linkping University

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 Linkping 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/

Jingjing Qian
masterthesiseng 2012/4/16 1:34 page i #1
ABSTRACT
Scania is a Swedish automotive manufacturer for heavy vehicles and engines.
It also oers transport solutions and long term commitment for customers.
In todays Scania, a modular system provides a huge variety of specications
to meet varying dramatic needs for dierent 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 eciency of designing
dierent 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 oers product database management for virtual
model design into CATIA, both CATIA and ENOVIA are developed
by the French company Dassault Systèmes 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 nally 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 nally be designed
into two separate modules, the rst part converts the XML extracted from
SPECTRA into an intermediate format and the second part is designed to
convert the intermediate le into the expected target le.
The intermediate le is required, since the format is independent of changes
i
masterthesiseng 2012/4/16 1:34 page ii #2
in both SPECTRA and ENOVIA. Furthermore, it is exible and less com-
plex to maintain than direct mapping from exported XML to ENOVIA.
The report focuses on ve parts, background, project specication, method-
ology, implementation, result and future work.
masterthesiseng 2012/4/16 1:34 page iii #3
PREFACE
This master thesis report was written at Scania CV AB in Sodertalje. This
thesis project constitutes the last part of my education in the Master of
Computer Systems program at Linkoping 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 rst. 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 ecient 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.
masterthesiseng 2012/4/16 1:34 page iv #4
ACKNOWLEDGEMENTS
First, I would like to thank the ILES group in Scania, who gave me the
opportunity to nish 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 nish our
project.
Especially I must oer 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 Jonsson at Linkoping University. Thank you for your
generous help.
masterthesiseng 2012/4/16 1:34 page v #5
ACRONYMS
AIX - UNIX OS dialect
CATIA - CAD-system by Dassault Systèmes
CAA - Component Application Architecture (C++ API)
CAD - Computer Aided Design
Control-M - Job Scheduler
DS - Dassault Systèmes
ECCO - Toolkit by PDTech, handles STEP
ENOVIA - PDM system can be combined with any CAD-system
ENOVDatax - ENOVIAs 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 dened
data
SIAM IP - Scania integration platform
SPECTRA - Scanias mainframe system for product structure
STEP - International standard for product data exchange
PDM - Product Data Management
PLM - Product Lifecycle Management
UML - Unied Modeling Language
XML - extensible Markup Language
v
masterthesiseng 2012/4/16 1:34 page vi #6
masterthesiseng 2012/4/16 1:34 page vii #7
Contents
1 Introduction 1
1.1 Problem Specication . . . . . . . . . . . . . . . . . . . . . . 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 le . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.2.1 EXPRESS . . . . . . . . . . . . . . . . . . . 14
2.4.2.2 Step le . . . . . . . . . . . . . . . . . . . . . 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 dierent parts in STEP 23
2.4.3 ECCO Toolkit . . . . . . . . . . . . . . . . . . . . . . 24
2.4.3.1 ECCO functionality . . . . . . . . . . . . . . 24
vii
masterthesiseng 2012/4/16 1:34 page viii #8
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 Specication and Goal 33
3.1 Project Specication . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Project Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 Module design and methodology 37
4.1 Design ow, 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 le importing obstacle in CAA . . . 42
5.1.2.3 Mapping language obstacle in CAA . . . . . 42
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.1 Proposed solution3: CAA + CAA . . . . . . . . . . . 48
5.3.1.1 CAA module in rst 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
A.2.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . 61
masterthesiseng 2012/4/16 1:34 page 1 #9
Chapter 1
Introduction
1.1 Problem Specication
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 oer product database management for virtual model design into CA-
TIA. Both of them are developed by a French company, Dassault Systèmes.
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 eciency of designing dierent products. The modular sys-
tem approach requires the system 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-
cic 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 specic 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 rst reason is ECCO
no longer supports the version of AIX in use on Scanias development and
production servers. This is a serious risk and a major obstacle every time
1
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-
cult 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 specically 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 beneted from each others
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 diered 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 specication.
Chapter 2. Background knowledge, introduction of the product structure,
system components, system architecture and development environment.
1.6. ABOUT SCANIA
Chapter 3. Project specication and goal.
Chapter 4. Presentation of system design and methodology.
Chapter 5. Dierent proposals for the solution, the analysis and comparison
regarding dierent 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 oers transport solutions and long term commitment for
customers.
Scania has over 100 years of history; todays 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 todays Scania, modular systems provide a huge variety of specications
to meet varying needs for dierent 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
eciency of conguring dierent products.
Infomate is a global world-class IT provider for Scania, providing IT services
supporting the business needs.
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-
tureand 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 ve 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 ow 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.
4
2.1. PRODUCT STRUCTURE
2.1 Product Structure
2.1.1 Product structure concept
A product is formed by several dierent 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 congurations
uniquely based on dierent 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.
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 dierent parts which have dierent
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 congured structures by formatting the le in XML.
Scania uses AROS interface to enter the data to SPECTRA. The following
picture shows the general view of AROS application.
Figure 2.3: AROS application
2.2.2 CATIA
Before the introduction to CATIA, there is a short introduction regarding
a company, Dassault Systèmes.
Dassault Systèmes: [1] is a world leading company in providing Prod-
uct Lifecycle Management (PLM) solutions for industrial process. Dassault
Systèmes 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 nd as much defective parts as possible, Scania simulates the
product using 3D visual tools. It takes products (CATIA, ENOVIA) pro-
vided by Dassault Systèmes 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ème. CATIA supports each stage of PLM, from conception to design,
manufacture, and recycling. CATIA covers dierent 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.
Figure 2.4: Example of CATIA [2]
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 specication
of the product, dierent types of the materials, and specication for the
development.
ENOVIA : Enovia Virtual Product Modeling products oers product data
management for virtual models and is integrated with design, engineering
and analysis solutions from Dassault Systèmes, providing the collaborative
platform for the companys 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 congurations. It is the database repository and
data management system for CATIA.
Figure 2.5: Example of ENOVIA [3]
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-
cic 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 les 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 le) 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.
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 les) sent from SIAM IP;
(2) Transformation, which means the XML le format would be transformed
into Enovia readable les (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.
Figure 2.8: Overview of JavaMigrator [4]
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 specication and
manipulation of the mapping between dierent 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 les 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.
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.
Figure 2.9: High level architecture from SPECTRA to ENOVIA
2.3. SYSTEM ARCHITECTURE
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 specied
conguration of the product is generated. SPECTRA generates an XML le
and the le 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 le will be converted into a Scania step le as an intermediate
le and nally 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 les: an XML le, a Scania step le and an Enov Datax
step le.
XML le: the XML generated from SPECTRA is a simple and readable
le 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 le 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 le: this is a step le which is the rst step of the trans-
formation, which means, this step le is an intermediate result; the data
resource of this step le is the XML le described before. The Scania step
le reconstructs the original XML le and denes the data in step le.
The reason for the existence of this intermediate step le between SPEC-
TRA and Enovia is twofold: one reason is that it is an independent le
which means any change in XML le or Enov Datax le would not eect
this le, 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 le: acceptable le by Enovia, a more complex format. The
resource of the mapping is the scania step le, schema of the Scania step
le, schema of the Enov Datax le and the mapping le represented in
EXPRESS-C. Regarding schema, it is an abstract modeling data le de-
ned by using EXPRESS language, which was introduced earlier.
2.4. STEP STANDARD AND ECCO
By importing the Scania Step le as a data source and schema as a data
structure and denition, the target le Enov Datax step le 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 ocially called Automation systems and integration - product data rep-
resentation and exchange ISO 10303 can represent 3D objects.
STEP is used in a lot of dierent industrial areas; it has been used in me-
chanical, construction, electricity & electronics, automobile, architecture,
etc. It has also been applied in elds 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 le
STEP File [7] is the most widely applied data exchange le of STEP. The
format of a STEP-File is dened in ISO 10303-21 Clear Text Encoding of
the Exchange Structure.
STEP is divided into dierent parts, each part represents dierent function-
alities according to the data exchange.
2.4.2.1 EXPRESS
International Standard ISO 10303-11:1994, specication of description meth-
ods, the EXPRESS data modeling language is used to give a general descrip-
tion of data models.
Functionalities:
EXPRESS is a data specication language, based on the entity relation-
ship model of data, and also includes constraint specications. It is widely
used in many dierent areas of business, industry, research and academics.
Modules described by the EXPRESS language can be performed by using
dierent 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 denes a general structure of the product data specication. 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 dened by an integer in
the example.
So similarly, here we could model a Company Name class to gather some
information about the company.
ENTITY company;
name: STRING;
END ENTITY;
2.4.2.2 Step le
Specication of implementation methods, an EXPRESS-driven data ex-
change le specication to save data model into les. The format of the
le 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 dened 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 species a mapping language for a relation-
ship description between dierent data formats in EXPRESS schema. This
means that EXPRESS-X is an evolving language describing the mappings
betweendierent entities, from one EXPRESS schema to another EXPRESS
schema that describes the view of the rst schema.
Figure 2.10: Overview of EXPRESS-X: [8]
Figure 2.10 gives a brief view of the relations between the dierent models.
The view model refers to the view of the original information model.
When we are using the EXPRESS-X to map dierent schemas, we use a
EXPRESS-X schema called mapping schema to perform the real mapping
between schemas.
The following gure 2.11 shows the schema mappings in an EXPRESS-X
specication.
Figure 2.11: Schemas in an EXPRESS-X Specication [8]
In gure 2.11, the mapping schema, which is represented as orange frames
denes the relationship between Base model and View model. In each model,
EXPRESS is used to dene the schema while the mapping schema is dened
in EXPRESS-X mapping language.
From gure 2.11, we could clearly see that the mapping schema takes the role
as a middleware component which connects two dierent 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;
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 denes
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 denes 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 denes the entity company
. The attributes name , employee name , employee age of the entity
are dened. Both base schema and view schema are dened 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
rst sets a condition by using WHEN ((person. name = family. Member.
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
denes the name of the base schema and the name of the view schema for
the mapping, which is uniquely dened.
But since the Express and Express-X are just abstract modeling languages
to describe the data type and mapping schema, we need source data dened
in the step le (xxx.p21 le) based on base schema to perform the real
mapping and get the target step le.
The following step le(xxx.p21) gives the source data based on the base
schema and target step le(xxx.p21 le) after the mapping.
Source step le:
#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 le 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.
Here is a simple gure 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 denition 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.
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 gure shows a brief comparison of the EXPRESS-C /X ap-
proach with the traditional approach.
Figure 2.13: Comparison of the EXPRESS C and X approach [5]
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 specication code length and up to 70% in development time can
be reduced.
2.4.2.7 Relationship between dierent parts in STEP
Figure 2.14 below describes the relations and dierent parts of STEP.
Figure 2.14: Relationship between dierent parts in STEP [9]
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 specication and manip-
ulation of the mapping between dierent data models. The transformation
between various data models are very dierent 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 dierent 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 denition
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 dierent 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 transformation based on dierent data models.
To be able to satisfy dierent requirements from dierent customers in
various research elds 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 dierent functionalities.
Here is an overview of the components of ECCO toolkit.
Figure 2.15: overview of components of ECCO toolkit [5]
2.4.3.2 ECCO compiler
A powerful compiler which can handle several dierent specication lan-
guages, including EXPRESS, EXPRESS-C, EXPRESS-X. Users can get the
specied target objects by choosing from dierent 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.
2.4.3.3 ECCO API
Figure 2.15 shows the major structure of the ECCO toolkit and its easy
to grasp it from the gure. 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 dierent databases. It also allows the ac-
cess to the STEP les(EXPRESS-based). It is an interface between external
data sources and applications.
Figure 2.16: ECCO data access library [5]
2.5. DEVELOPMENT ENVIRONMENT
In the gure 2.16, schemagen refers to the tool to generate EXPRESS-
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
dierent schemas are not as common as usual, It is also dicult 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èmes, 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èmes
products CATIA, ENOVIA, DELMIA. To be able to oer customers an en-
vironment for developing their specic requirements, CAA provides a mod-
ularization programming of the system. The customized solution is based
on the dierent customers dierent requirements so it is exible and con-
venient for dierent 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 dierent in
detailed.
Workspace:
In CAA, the workspace takes the responsibility of organizing and storing de-
velopment projects. Workspace has its own name dened by the developer.
Workspace could include more than one framework.
The framework in CAA is a mapping to projects. A project is dened as a
set of les that produces a program/library or a nal binary le. 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 gure 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 les 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 dierent 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 les
in ProtectedInterfaces cannot include header les 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.
The functionalities of these three interfaces are dierently based on this
access scope. Customers can use dierent interfaces depending on dierent
needs.
In the source le folder included in the module, the major program (usually
.cpp le ) can be added and run as an executable le. Also, make les
sux mk is placed in the form of Imakele.mk in each module. The
functionality of makele is as same as the regular makele, which links to
the specic components, systems, or some specic 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 briey. 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 dened data, such as STEP API. It provides a binding with spe-
cic 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 le 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 les. 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 specic module is to create and
delete the SDAI modules. To be able to convert the source le to the target
le, there is a specic 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 specic CAA components dened in the CAA environment, the
makele 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.
The compiling from EXPRESS-X to C++ module in CAA:
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
specic modules in CAA. Also, the Imakle.mk will include all the modules
related.
One of the deciencies of the application to convert EXPRESS-X schema and
EXPRESS schema in CAA module is the limitation service and functionality
from Dassault Systèmes. In order to be able to convert from a step le
(It is called Scania newStep le in the project ) to the format of another
step le (target step le, it is called ENOV Datax in this project), we are
suppose to get four dierent les, which are: the source le (Scania newStep
le) , the EXPRESS Schema which describes the Scania newStep le, the
EXPRESS-X mapping le (which is used to map between dierent schemas),
and the EXPRESS schema which describes the target step le ENOV Datax
le.
The relationship between the dierent step les and schemas can be repre-
sented in the following gure 2.18:
Figure 2.18: SDAI source and target les
When we are trying to map between dierent schemas, we rst need to
use interface in the CAA module to create SDAI module, then the SDAI
module would run with the source step le and the result of compilation of
EXPRESS and EXPRESS-X schemas.
But in the current Dassault Systèmes CAA module, there is no functionality
to create a SDAI module to fully support the reading and writing of the
source step le Scania Step File. The target step le ENOV Datax le could
not be gotten directly by using the current solution provided by Dassault
Systèmes.
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 specic entities in a
dened 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 dierent 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.
Express Compiler:
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 gure 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.
Chapter 3
Project Specication and
Goal
3.1 Project Specication
In the existing system, ECCO takes the responsibility for the transformation
between dierent data models. It transforms the XML le to an intermediate
le called scania step le and nalizes the transformation by producing a
nal format which the ENOVIA server can accept, the Enov DataX le.
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 todays 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 specication language and the standard data
access interface between the abstract language and lower level language. It is
dicult 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.
33
3.2. PROJECT GOAL
Figure 3.1: Project Specication
3.2 Project Goal
This project is mainly about a transformation between dierent data mod-
els.
Figure 3.2 species the source le and target le, the gure separates the
whole task into two parts.
3.2. PROJECT GOAL
Figure 3.2: Source le and target les specication
In the rst step, the source le refers to the XML le and the Scania schema.
XML is explained in section 2.3. Scania schema is an express le which
describes the attributes of entities in the XML le and the child-parent
relationships between dierent entities in the XML le. Basically, it is a
structure specication for the XML le. The XML le should be loaded
into the designed module, run together with Scania schema, generating the
intermediate le, called the Scania step le.
After the intermediate le is generated, it would be loaded into the second
module. In the second module, the source les are the Enovia schema,
Scania schema, the mapping le and the Scania step le. Enovia schema
is an express le which represents the complicated relationships between
each element in the target Enov DataX le. The Scania schema is the same
schema used in the rst module, the mapping le is an EXPRESS-X le
which maps the Scania schema to Enovia schema le. By using this module,
the Scania step le is loaded as a source le and the mapping le takes the
transformation from Scania schema to Enovia schema and the target le
Enov DataX le is generated.
The intermediate le is required, since the le is independent of changes in
both SPECTRA and ENOVIA. Furthermore, it is more exible 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 le architecture between source le and target
3.2. PROJECT GOAL
le.
Figure 3.3: Source le and target le Architecture
Chapter 4
Module design and
methodology
This chapter is focused on the design ow and methodology used in each
design step.
4.1 Design ow, methodology
Figure 4.1 shows the design ow from system level to lower level. The
design of the solution in this project mainly follows the design ow and
methodology as shown below.
The design ow 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 ecient method.
The lower level design is actually a coding design phase in the whole design
ow. It takes the integration of software and hardware, claries 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 ow starts from the informal specication constrains, which gives
a very general and informal instructions regarding to the project.
Modeling followed by informal specication refers to the generation of for-
mal specication of the functionalities in the model. The model could be
decided to be used based on dierent modeling concepts. Model in this
stage can refer to, for example, the C model, UML model, etc. Regarding
37
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 dierent
proposals.
4.1. DESIGN FLOW, METHODOLOGY
In the system model step, the rst 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 gure 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 dierent
ways. In each solution the advantages, disadvantages and limitations are
considered.
In gure 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 satised.
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 eciency.
Lower level:
In this level, the execution on a programmable processor, data ow, soft-
ware model, API are all decided, as well as the hardware platform. The
hardware and software in this implementation phase have to be developed
in a coordinated way. Relating to this project, we dont have any special
requirements for the hardware; a normal computer or laptop satises 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 gure is divided into dierent stages:
(1) Encoding implementation language, like Java, C++, EXPRESS, EXPRESS-
X.
(2) Compiling of the code by using dierent software components.
(3) Code adapting to the existing operation system and environment. The
data consistency should be considered and fullled.
(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 unsatised the project
goal, the solution would be estimated again and the work will be started
again from the architecture selection in system level design.
Chapter 5
Implementation
By following the methodology and design ow 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 dierent 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 rst part is designed to
convert from the XML le to intermediate le, the Scania step le. The
second part aims to convert from the intermediate le into the target le,
the Enov DataX step le.
5.1 Proposed Solution 1 and implementation
5.1.1 Proposed solution 1: CAA + CAA
As described in the project specication 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èmes and user manual and documenta-
tions are provided by them. After we investigated and explored the docu-
ments, the following solution was proposed.
40
5.1. PROPOSED SOLUTION 1 AND IMPLEMENTATION
Figure 5.1: Proposed Solution1
Regarding the gure 5.1, the whole solution is divided into two parts, each
part is developed in the CAA module. The rst CAA module takes the
XML le and Scania Schema as input and gets the Scania step le as an
intermediate le, the second CAA module takes the Scania step le as input.
By compiling the mapping le, the target Enov DataX le is generated as
a result. After the le 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èmes, 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 rst CAA module, the XML le is taken as the data source, with
the help of CAA module, XML is supposed to be converted into a step
format le. XML handles complex relationship between dierent objects.
The following gure 5.2 represents the objects relationship in the XML le
as an example.
Figure 5.2: object relationships in XML
5.1.2.1 HASHTABLE functionality obstacle in CAA
In the gure 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
dierent objects in XML le. To be able to pass the XML as resource to the
CAA module and convert to the Scania step le, XML parser functionality
is needed to be able to recognize dierent hierarchy relationships between
dierent 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 rst layer under object 1.1. To be able to nd
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 dierent entities would be found. But in the current CAA module,
the HASHTABLE functionality is not supported.
5.1.2.2 Source le importing obstacle in CAA
In the second module, the intermediate le Scania step le is taken as the
source le. To be able to be converted to the target le 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 doesnt support the import
of the step le. Also it doesnt support the customized functionality to
support the step le import. This means, there is no source le that could
be loaded into the module and it is impossible to get the target le.
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 specic document called provision document is suppose to be
generated along with the target le to meet the system requirement. The
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 specic 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 specic 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 rst 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 nely integrated with JAVA Migrator in
the system architecture.
The new solution takes the responsibility of solving obstacles and limitations
in proposed solution 1 to get the target le.
5.2.1 Proposed solution 2: JAVA + CAA
The solution is designed in two modules, the rst part is developed in JAVA,
and converts the XML le to a new Scania step le, which is dierent from
the old Scania step le described in section5.1.
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 dont support some mapping
functionalities which CAA supports. Based on the documentation Dassault
Systèmes provided, it is possible to convert the new Scania step le into
Enov DataX le 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 dened in
the EXPRESS format.
In the rst solution, the HASHTABLE functionality is required so that
dierent entities in the XML le could be recognized and organized, but
CAA couldnt fulll it. JAVA supports the HASHTABLE functionality
and makes the hierarchy relationships between dierent entities in XML
le to be recognized. So the XML le is the data source, while the Scania
schema here is similar to a lter and structure to get the entities in XML
le and structure them in a hierarchy way.
Figure 5.5: XML le and the old Scania schema in the JAVA module
5.2.1.1.2 New Scania schema In the rst solution in section 5.1.2.3
we introduced the mapping language obstacle in CAA. In the second module
of the rst 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 gure represents the
complicated relationships in the old mapping module.
Figure 5.6: Complicated mapping relationships from the Scania Schema to
the Enovia Schema
In gure 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.
It is the reason why ECCO takes EXPRESS-C to perform the mapping.
But in CAA, EXPRESS-X doesnt have strong functionality to handle the
complicated mapping functionality.
Figure 5.7 could help to understand the complicated mapping relation-
ship.
Figure 5.7: Simplied view of mapping relationship
The complicated mapping relationship could be viewed in two parts, the
rst part handles the complicated features in the mapping. The implemen-
tation of this part is very close to C implementation. 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 rst part in gure 5.7 is used in the rst JAVA module, the second part
(pure mapping) part is used in the CAA module.
The new Scania schema is created to handle the rst 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
gure 5.5 will be read. Finally the new Scania step le is generated. The
format of the new Scania step le is very similar to the target le 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 le is a new Scania
step le as intermediate le to be imported as a source le in the second
CAA module. The class diagram and sequence diagram in UML is attached
in A.1 and A.2.
5.2.1.2 CAA module
As was discussed in the rst solution, CAA doesnt have any API to import
step les into the CAA module, section 5.1.2.2 has introduced the obstacles.
But if the step le couldnt be loaded into the module, the task became
impossible to nish. This is a big bottleneck in the task. Dierent methods
were tried and it was nally found that there exists a Korn-Shell written
script named IEnovIn.sh developed by Dassault Systèmes to help to im-
port the step data into the ENOVIA server.
Based on the documentation provided by Dassault Systèmes, IEnovIn.sh is
used in two dierent ways based on customersdierent requirements.
The rst method is importing the step le in the Enovia acceptable format
into ENOVIA server directly.
The second method is by using the IEnovIn.sh le and an expected mapping
module (map from new Scania schema to Enovia schema) dened in CAA
module. Any step les could be transformed into Enov DataX format and be
imported into ENOVIA server. Regarding the solution, the second method
is taken.
Here is the architecture to describe the data import by using IEnovIn.sh
Figure 5.8: Data Import architecture by using IEnovIn.sh
In Figure 5.8, the import tool refers to an XML le to guide the mapping
module, name of step le and where to nd the SDAI data from the CAA
module. Dassault Systèmes developed this tool to import the data in an
ENOVIA acceptable format into ENOVIA server, according to the docu-
mentation provided by Dassault Systèmes, this solution should work.
After the solution is decided, a lot of experiments were tried. The import-
ing is completed by following two steps: rstly it maps the step le into
Enov DataX le and then to be imported into ENOVIA server. The im-
porting is performed in ENOVIA server.
After being compiled successfully in CAA environment, the importing comes
to an execution error. The target schema and source schema couldnt be
recognized in ENOVIA server although the mapping le could be. Dierent
mapping modules and step les were tried, but it still couldnt make the
importing task nished. It became a bug in the importing step.
An urgent service request has been assigned to Dassault Systèmes, it is
handed into the research and development team at Dassault Systèmes, the
issue is still under investigation.
Implementation of solution2:
Figure 5.9: Implementation for proposed solution2
5.3.1 Proposed solution3: CAA + CAA
The JAVA module introduced in section 5.2.1 is an appropriate module to
generate the intermediate step le, as t is a standardized module. Also,
the JAVA programming language is widely used by software developers, but
the intention of this project is to try to use the CAA module or another
standardized module to match the project goal, so an alternative solution
which aims to develop a new CAA module to reach the project requirement
is created.
As was discussed in section 5.1.2.1 , HASHTABLE functionality is needed
but it is a big obstacle in designing a CAA module to perform the rst part
function. This failure led to creating a new solution to perform the rst part
transformation.
Collection Class
To be able to process dierent XML les in dierent sizes, a collection func-
tion could be taken as a solution.
Collection class is a container class that holds each item with a specic type.
Figure 5.10: Collection Class example
For example, in gure 5.10, there are six blocks on a board, each has its
own color, position and status(active or not). It is a simple example to help
understanding that the collection class allows user to have access to each
block with specic properties.
Related to the task, in dierent cases, XML les have dierent sizes, so
searching around the XML les based on dynamic storage is required and
collection class would fulll the requirement.
CAA has its own collection framework but it doesnt support the dynamic
storage based on various data sizes. XML les couldnt be processed with
the help of CAA collection.
But fortunately, C++ STL container is supported by CAA API. By using
the STL container, the XML le could be processed and the searching and
storage requirement could be fullled. It provides a wider thinking about
the HASHTABLE replacement in the CAA module.
In the second CAA module, since Dassault Systèmes doesnt support the
importing of step le, the IEnovIn.sh importing method is taken as a possible
solution although it is still under investigation in Dassault Systèmes now.
The whole structure can be viewed in gure 5.11.
Figure 5.11: Proposed Solution 3
5.3.1.1 CAA module in rst part
The rst CAA module is designed to convert the XML le into a Scania
step le. The intermediate result generated by the rst module is the old
Scania step le which was introduced in section 5.1.1
Scania schema
Scania schema here refers to the old scania schema introduced in the rst
solution in section 5.1.1, it is not modied or updated in the third solution.
It doesnt relate to the new Scania schema proposed in section 5.2. The
complicated mapping relationship is still handled by the second CAA module
by using user function.
C++ STL container
STL stands for the Standard Template Library. It is a C++ library of
container classes, algorithms and iterators. Almost every component in the
STL is a template. Containers: it is a container which contains dierent
classes such as vectors, hash maps, lists. The usage of vectors is similar to
C arrays but without the management of dynamic memory allocation. Hash
map is a pair associative container that contains value like this:(key, data).
It is used in the CAA module to nd out the corresponding data based on
the key. So this functionality fullls the HASHTABLE functionality.
5.3.1.2 CAA module in the second part
As was discussed before, the complicated mapping relationship needs to
be handled in the second CAA module, but the mapping relation is very
complex as was explained in section 5.2. But with the help of user functions
in CAA, the solution became possible.
User functions:
The mapping module is too complicated to be written in the CAA envi-
ronment but the user function embedded in CAA is explored to take the
responsibility to handle the implementation of C++ features during the
mapping.
The code in CAA is binding with the user function. Basically, the EXPRESS-
C feature could be performed in the CAA module in combination with user
functions. The user functions could be viewed as the rst part in gure 5.7.
In the second solution, the complicated implementation in C is performed
by a new JAVA schema, but in this third solution, it is taken by the user
function.
Along with the mapping module in CAA, a specic module in user function
is taken to perform the complicated mapping between the Scania schema
and the Enovia schema. The result of using the user function is to get the
mapping result from the mapping module.
But because the existence of obstacles in the step import in the CAA mod-
ule, the expected le has to be generated and imported with the help of
IEnovIn.sh.
Implementation of solution3:
Figure 5.12: Implementation for proposed solution 3
In the third solution, the rst CAA module is successfully developed and
the expected intermediate le is generated. The class diagram and sequence
diagram are attached in A.4 and A.5. Also in the second CAA module, the
mapping functionality is performed successfully (sequence diagram in UML
attached in A.6) but the nal result still failed due to the IEnovIn.sh import.
As long as Dassault Systèmes doesnt solve the importing script issue, the
expected result couldnt be achieved. It became a big obstacle in both the
second and third solution. It also became a key obstacle which eects the
whole project.
Chapter 6
Conclusion and Future
Work
Having spent ve months gaining experience and knowledge through this
project has been a great asset to me. During the course of this project I
have developed my problem solving skills, gained a great deal of technical
expertise, as well of having got a deeper look into an industrial environment
highly relevant to me and my education. Although there have been obstacles
and limitation along the way, they have been overcome and surpassed, and
the project ended with positive results.
In this project, two dierent solutions to the given problem were developed.
These solutions use dierent methods and go in dierent directions.
The JAVA+CAA module oers a lot of advantages in the project solution.
In the rst JAVA module, the solution is designed in a modular programs
way, it creates objects, manipulates objects to make the objects work to-
gether. The module is exible and easy to update or modify based on
dierent requirements. It also uses automatic memory allocation so that
the complexity to allocate the system memory can be skipped.
Besides the advantages of JAVA programming language, the JAVA module
provides the developer a good view of the complex mapping relationship
between dierent entities. It manages the complex mapping relationship in
a readable and reusable way. Readers who have knowledge in JAVA could
easily read the code which represents the mapping between base schema and
target schema.
The reason for why CAA module is taken as the second solution is because
some limitations in the JSDAI API. It is not a widely used API; the LKSoft
company also has some limitation to support the application of JSDAI at the
53
moment and it doesnt support EXPRESS-X mapping specications. This
is the biggest reason why the second module is designed in a CAA module.
The CAA module takes the responsibility of converting the intermediate le
to the target le, but due to the function obstacles from Dassault Systèmes,
the nal result depends on their support.
CAA API is a very creative design in the area of software modularization.
Several developers are able to design their own individual module in the
system at the same time and not eect each other. It oers the developers
a exible and ecient environment to design the system. It divides com-
plex problems into simple parts independent and make the system easier to
understand and update.
However, the support and documentation from Dassault Systèmes is poor.
Since CAA it is not a widely used API, the development of a system is more
or less based on Dassault Systèmess support. It is not easy to get in in the
beginning of the development, also the support and development of Dassault
Systèmess product depends on the popularity of the product. If it is not
a widely used application like the product data development products, the
support is poor even when they provided the solution according to their
documentation.
The achievement of the project gives the existing system a good solution if
Dassault Systèmes could provide a successful result according to the IEn-
ovIn.sh issue in their system. Developers could choose any of the two avail-
able solutions to execute the convertion from XML le to Enov DataX step
le. Also, when the target step le is asked to be changed based on cus-
tomer requirement, it could be easily achieved when the mapping module is
changed based on customized schema.
Bibliography
[1] WIKIPEDIA. http://www.en.wikipedia.org/wiki/Dassault Systèmes.
[2] WIKIPEDIA. http://www.en.wikipedia.org/wiki/File:CATIA cre.jpg.
[3] Dassault Systèmes. http://www.ntsconsulting.ca/enovia.php.
[4] Norin Jonas. Overview of java migrator. SCANIA, SE-151 87
Sodertalje, Sweden.
[5] PD Tec. Albert-Nestler-Str. 10, D-76131 Karlsruhe, Deutschland.
http://www.pdtec.de.
[6] WIKIPEDIA. http://en.wikipedia.org/wiki/ISO 10303.
[7] WIKIPEDIA. http://en.wikipedia.org/wiki/ISO 10303-21.
[8] Martin.Hardwick Ian.Bailey, David L. Spooner, Rensselaer Polytechnic
Institute, Adrian.Laud, and South Bank University. Overview of the
express-x language.
[9] Dassault Systèmes. Overview of step. 10, Rue Marcel Dassault, 78140
Velizy-Villacoublay, FRANCE.
[10] JSDAI. http://www.jsdai.net/.
[11] Petru Eles. Tdts07 system design and methodology. LINK
OPING UNI-
VERSITY. http://www.ida.liu.se/ TDTS07/lectures/lect1-2.frm.pdf.
[12] LKSoft. http://www.lksoft.com/.
55
Appendix A
UML Files
A.1 JAVA+CAA Module
56
A.1. JAVA+CAA MODULE
A.1.1 Class Diagram
Figure A.1: Classes Diagram in JAVA + CAA module
A.1.2 Sequence Diagram
STEP1: JAVA Module
Figure A.2: Sequence Diagram in the rst step JAVA module
STEP2: CAA Module
Figure A.3: Sequence Diagram in the second step CAA module
A.2. CAA+CAA MODULE
A.2 CAA+CAA Module
A.2.1 Class Diagram
Figure A.4: Classes Diagram in CAA + CAA module
A.2. CAA+CAA MODULE
A.2.2 Sequence Diagram
STEP1: CAA Module
Figure A.5: Sequence Diagram in the rst step CAA module
A.2. CAA+CAA MODULE
STEP2: CAA Module
Figure A.6: Sequence Diagram in the second step CAA module

CAA Product Structure

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CAA Product Structure

Hochgeladen von

Copyright:

Verfügbare Formate

Institutionen fr datavetenskap

Department of Computer and Information Science

Das könnte Ihnen auch gefallen